OTA update fails in CC3200

Thanks!

sundares80 Would you be able to modify a device you have access to in order to have it not send the additional new line as a test? If you can verify that fixes the issue, I can ask the team to look into changing the server to allow that (though please note I can't make any promises on that).

Greg-DB, as you mentioned too (and now I'm pretty sure you're right) the alert is "Close Notify"! A look on the sources shows that there is no way TI client to avoid adding one more empty line at the end... modeling only confirms it. That's it.

Experimenting with other sites shows that most sites ignore additional blanks after requests.

Of course this reflects TLS traffic since TLS wraps HTTP. 🤷

Add:

---

Greg-DB wrote:

... I don't see "Bad Request" or "400" mentioned in this thread before. ...

---

I'm a bit confused of above. 🤔 Did you expect to see it? If you have seen something similar somewhere it had definitely not been encrypted. 😉 Let's recall what we are talking about is encrypted piece of data! That's why it's difficult to discover such a thing on first look.

Здравко I can reproduce the 400 Bad Request using your code snippet, but can you clarify how you determined that this "Bad Request" issue is the cause of the problem originally reported in this thread? I don't see "Bad Request" or "400" mentioned in this thread before. The original poster seems to have reported the issue as being in the TCP/IP or TLS layer instead. Thanks!

Actually there is a way to be solved discussed issue. The existence of empty lines is not something defined in HTTP standard, but also it's not something denied (not explicitly at least). 😉 Many present day servers also ignore such extra blank symbols, if any, at the request end. I don't know if Dropbox may decide to do the same, but if so that wouldn't be an issue anymore. (No more Bad request response - provoked by this empty line - directly following OK response)

Good luck.

sundares80 While that SSL Labs SSL Server Test tool is not made by Dropbox and I am not an authority on it, my understanding is: The cipher being marked orange instead of green only indicates that the cipher is considered "weak", and does not indicate anything about the the server's use of the cipher. The inclusion of the cipher in that list at all indicates that the server supports that cipher. That "weak" is a description of the cipher itself, not the server configuration.

That being the case, it's not possible for us to change that cipher from orange to green. We could only remove it from that list for our servers entirely.

sundares80, I don't want disappoint you, but the cipher in use has nothing to do with your issue. Even more: Any server cannot select something client hasn't provided! If you count that as some possible other issue - it's your responsibility.

ЗдравкоThank you for your analysis. Yes, we agree. We have to redesign our HTTP client library. but I cannot access the physical IOT device since it is installed in multiple locations in the US and Europe. The only way I can update the client code is by doing an OTA update.

Greg-DB/Здравко

As per the packet capture, our IOT device support below chipers.

When I scan drop box server with below link, I see only warning message (Weak cipher) for one cipher which is used by the device. If you help to change it to green, I belive this issue is going to resolve.

https://www.ssllabs.com/ssltest/analyze.html?d=api.dropbox.com&s=162.125.8.19

Regards,

Sundar 

---

sundares80 wrote:

... The only thing we can do is perform an OTA update, which is currently not working due to your changes. ...

---

Hi sundares80,

I don't know what do you mean with "your changes", but I'm a regular Dropbox user, like you, and complain about different imperfections (very often bugs), the same like you do. I can "remove" something as much as you can - neither more nor less. Following this context line, did you check your code for bugs? 🧐 I'm already pretty sure there are such that lead to the result you're observing. You can model the behavior of your device (and your code accordingly) with following curl command:

TOKEN="PUT YOUR ACCESS TOKEN HERE"
NL=$'\r\n'
curl -v https://api.dropboxapi.com/2/users/get_current_account -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -H 'content-length: 4' --http1.1 -d "null$NL" -: https://api.dropboxapi.com/2/users/get_current_account -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -H 'content-length: 4' --http1.1 -d "null$NL" > /dev/null

The command curl is more stable and continue work, but the same "noise" in the communication may be observed. Comment this with your TI support if you want. Or rather if they want to do such a commenting with you... 😁 Would be pretty inconvenient to them!

Good luck.

PS: sundares80 don't use their buggy libraries, but rather some third party library or reimplement the HTTP communication yourself to passaround current bugs.

Здравко Thanks for writing that up! I'll pass it along to the team.

Hi Greg-DB,

Yes, I may got confused about the exact code. I tried to reproduce it right now - unsuccessful.

There is other strange situation though. Dropbox server refuses to renegotiate! Despite this activity support is optional, it's highly recommended (according to RFC 5246). About Client Hello:

---

When this message will be sent:

   When a client first connects to a server, it is required to send

   the ClientHello as its first message. The client can also send a

   ClientHello in response to a HelloRequest or on its own initiative

   in order to renegotiate the security parameters in an existing

   connection.

---

About "TLS protocol issues":

---

While renegotiation is an optional feature, supporting it is
highly recommended.

---

When some client tries renegotiation, Dropbox response is:

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Alert (21)
  Length = 18
    Level=fatal(2), description=no renegotiation(100)

 Hm...🤔 According documentation, such a message should be warning, not fatal!  Again, RFC 5246 states:

---

no_renegotiation

   Sent by the client in response to a hello request or by the server

   in response to a client hello after initial handshaking. Either

   of these would normally lead to renegotiation; when that is not

   appropriate, the recipient should respond with this alert. At

   that point, the original requester can decide whether to proceed

   with the connection. One case where this would be appropriate is

   where a server has spawned a process to satisfy a request; the

   process might receive security parameters (key length,

   authentication, etc.) at startup, and it might be difficult to

   communicate changes to these parameters after that point. This

  message is always a warning.

---

This is a step aside from OP, but I just discovered it and that's why I'm mentioning. Such a message doesn't let a chance to client to decide whether to proceed further (without renegotiation) or not! This is not an issue in particular situation since there is no preceding handshake in the shared pcap, so that alert cannot be such a type (despite no way to be certain since encrypted).

There is another thing that may be interesting in context of OP. As can be seen (if we assume the alert is "close notify"), it comes from server side, not from client side (as it usually does). Such thing is possible only when in the request is header "Connection: close" or I was not able to reproduce it in other situation at least. So to be possible confirmation or rejection of this supposing (inappropriate header), sundares80  should send plain request to pseudo-server (like netcat, for instance) and see if there is some unintentional header. I suppose wouldn't be possible SSLKEYLOGFILE usage since most probably the application doesn't support it.