I am new to TLS/SSL. I am facing an issue with SSL/TLS connectivity.
I could see in tcpdump traces that the handshake is done succefully(clienthello,serverhello,certificate,certifcate request,server hello done, client certificate, client key exchange,certificate verify,change cipher suite exchange and finished message from both server and client side). My understanding is that if finished message exchnaged means handshake is completed. Is it correct?
After 'finished' message, Client sending application data which is http get request. There is no response from server for ~2 minutes and client is sending an alert close_notify after that.
"11905 14:51:54.122049 10.62.73.221 10.62.68.4 TLSv1 105 Alert (Level: Warning, Description: Close Notify)"
Alert message 21 is received by server.
could any one please explain why the alert message has been received by server.?
Thanks for support.
Well, with the details in your question, it could be that the GET request is not properly formed or the TLS Record is not proper - perhaps there is a discrepancy in the payload specified and what it is. Are you constructing the TLS Record on your own or using an established library? It seems, that since you are new to SSL, an established library is being used. In this case, please make sure that the GET Request is formatted as per the HTTP spec with the necessary HTTP headers.
close_notify is normal. Nothing to be alarmed about. It is just the TLS version of close().
Related
I am working on TLS 1.2 Cipher TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, After send the application data server throw an error message Encryption alert (21).
I observed on the wire shark log there is no Finish packet from the client even though server starts next communication.
Please give me the support. Thanks advance.
can anyone clarify what the MQ "Prot Algorithm" bit of the ECapFlags3 struct is for and/or does, and why and when it gets set by IBM MQ during a connection setup?
At a high level, we're implementing an SSL offload configuration for a client (Mulesoft) to connect to an IBM MQ queue via an F5. Whenever we enable SSL, the connection fails. With TLS off, the data flow works fine. (it's not something basic, like not sharing an acceptable cipher, etc. - the TLS handshake completes between the Mulesoft client and the F5 fine, and data flows - but the client appears to stop the connection). We don't see any difference in what the F5 sends over to IBM MQ in either case; the only difference we can find is that the IBM MQ replies all have the ECapFlags3 "Prot Algorithm" bit set, when TLS is enabled between the client and the F5.
In performing captures, we note the following:
With TLS on, the TLS handshake completes apparently without issue, and MQ packets do go over to the IBM MQ
With TLS on, we see two "INITIAL_DATA" MQ requests go over, and receive responses back; immediately after that, the client sends a TLS alert
With TLS off, we see the same two INITIAL_DATA messages and responses, then the client sends credentials (i.e., sends a "USERID_DATA" message)
We see no unexpected differences in the first 2 exchanges (the INITIAL_DATA calls) with or without TLS, except that the MQ reply, to both INITIAL_DATA calls, has the msb of the ECapFlags3 set; this bit is labeled as "Prot Algorithm" by Wireshark
The whole exchange happens within 300ms when successful (no TLS), and within less when TLS is enabled, so no timeout should be occurring.
Our working hypothesis is that the "Prot Algorithm" bit being set is having some effect on the client; correction would involve either preventing it from being set, or adjusting the client configuration to handle it cleanly.
Any information on that flag bit - or any other thoughts! - welcome. Thank you!
Consider this scenario:
[wanting to write] [sent token success]
Application -------> SSL ----------->
| *peer drops*
[waiting to read] |
***blocked***<------------
In other words, your application wants to write something, but the SSL internal state is WANT_READ. On the other end, the peer connection has dropped.
Can SSL detect this through some keep-alive check of it's own? What can you do in this case?
SSL usually leaves detection of connection problems to the underlying transport layer, i.e. TCP. This means that by using TCP keep alive it can be detected if the peer vanishes without proper connection close. Apart from that there is also the heartbeat extension at the TLS level but contrary to TCP keep alive it is not universally supported.
If SSL detects a connection that hasn't been correctly terminated from SSL's point of view via an SSL close_notify message, it will regard it as a truncation attack, and will give you an error message or an exception, depending on which API you are using.
your application wants to write something, but the SSL internal state is WANT_READ. On the other end, the peer connection has dropped.
What it wants you to read is either the close_notify or the error message or exception. Whatever the case, when it says WANT_READ, you have to read.
This is a question which I believe the RFC is silent about: https://www.rfc-editor.org/rfc/rfc5246
When an SSL connection is established, and application messages being exchanged between client and server, if at a pt of time a renegotiation is triggered, what should happen to those application messages that are sent while both ends are still negotiating.. ?
Are they discarded ?
Do they cause renegotiation to fail ?
Thanks !
They are not discarded and they do not cause renegotiation to fail. They are encrypted using the existing session key until the ChangeCipherSpec message has been sent, after which they are encrypted with the new key. That applies in each direction separately. The implication is that they can be interleaved with the handshake messages, although whether any of the existing APIs can actually provide a way to do that is another question.
I have a situation where my (non netty) client is closing the SSLSocket but not the underlying Socket. This does exactly what would be expected it sends a close_notify to the server, which replies with a close_notify.
However my server is Netty based, and uses SSLHandler, by adding a LoggingHandler() I can see it getting the close_notify, and responding with a close_notify. The problem is my upstream handlers get no notifications at all, as the underlying Socket is not closing so there is no disconnect. I specifically want the sockets to remain open.
What I need is to get a notification that the SSLHandler has shutdown, so I can remove the SLLHandler from the pipeline and continue communicating with normal TCP.
Is this possible in Netty?
As part of my investigations I tried closing the SSlHandler from the server/netty side, and that would work except Netty closes down the sslhandler before getting the clients close_notify (as per design and spec), the trouble is that any subsequent read of the underlying socket gets that close_notify as raw data as the SslHandler has shutdown. If possible I would rather not have to write a handler that duplicates the SslEngines job of reading SSL messages. I understand why SSlHandler does not wait for the clients close_notify reply, which is why I tried to do it from the client side where I have more control of the SSL sockets.