If I use TCP as the transport protocol and want to secure the line with SSL or TLS, does SSL/TLS Handshake happens after TCP Handshake?.
SSL/TLS works on top an already established communication channel, i.e. the TCP connection has to be established (and thus the TCP handshake successfully finished) before the TLS handshake can start.
Related
I've got a web application with nginx supporting https with TLSv1, TLSv1.1, TLSv1.2 protocols. We'd like to stop supporting TLSv1 and TLSv1.1 due to well known security vulnerabilities. Unfortunately, we have some legacy clients running very old OSes that cannot be upgraded to connect over TLSv1.2. As a solution would it be possible to place a proxy in front of our web app that takes traffic solely from these legacy clients and have that proxy support decrypting TLSv1 but re-encrypt that traffic using TLSv1.2 before proxying it forward? Is this something that nginx can do? Would the responses returned to the client be encrypted with TLSv1?
Quite strange issue
I have mosquitto broker working with TLS
It is correctly accessible by an MQTTfx client set up for 'Enable SSL/TLS, TLSv1.2, CA certificate file'
The same ca.crt file is used by a openwrt mosquitto client issuing
# mosquitto_pub -h x.x.x.x -p 8883 --cafile /etc/mosquitto/certs/ca.crt -i 1.1.1.1 -t test -m 123 -d
it returns
Client 1.1.1.1 sending CONNECT
Error: A TLS error occurred.
At the orher end, the broker, shows
OpenSSL Error: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
Socket error on client (null), disconnecting.
What is messing me up is the fact that the MQTTfx client instead is accepted, and it's using the same certificate..!
New connection from y.y.y.y on port 8883.
New client connected from y.y.y.y as 180ce1c04c1944e1964608221efbcf0a (c1, k60).
Sending CONNACK to 180ce1c04c1944e1964608221efbcf0a (0)
Should mean that the certificate is valid and trusted... isn't it?
What's wrong then with the other client using the exact same certificate file ?!?!
...at the end using --insecure option did the job.
Means verification of the server hostname in the server certificate.
Well it works, although using this option in a production environment potentially invalidates the use of encryption.
I am trying to troubleshoot an issue where connection is reset.
When i captured the TCP packets in wireshark, I see that Version is shown as SSL2.0 and then after Handshake Message Type, it shows TLS 1.2.
Actually my server only accepts TLS 1.2.
Please help me to understand if client initiated SSL v2.0 or TLS 1.2?
SSLv2 Record Layer: Client Hello
[Version: SSL 2.0 (0x0002)]
Length: 257
Handshake Message Type: Client Hello (1)
Version: TLS 1.2 (0x0303)
Cipher Spec Length: 216
Session ID Length: 0
Challenge Length: 32
Cipher Specs (72 specs)
Challenge
I receive the following nginx log frequently and unable to get any suitable answer from google search. My nginx is having a valid SSL certificate.
Jul 15 08:21:58 web-lb01 WEB_LB01_443: 2016/07/15 08:21:58 [info]
5753#0: *7101 SSL_do_handshake() failed (SSL: error:140943F2:SSL
routines:SSL3_READ_BYTES:sslv3 alert unexpected message:SSL alert
number 10) while SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443
Keep an eye on the Ciphers and protocols like TLS1.2,TLS1.1, TLS1.0 are enabled . SSL handshaking comprises of not only the SSL certificate but also a common set of ciphers and protocols are negotiated between the client and the server for further encryption.
The failure is intentional and is because SSLv3 is disabled. A .NET client is defaulting to using SSLv3 and it won't retry with a supported SSL version without receiving an alert before a failure.
I've got OptRenegotiate set as per http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#ssloptions, but my server is still returning an SSL handshake failure, rather than alerting handshake failure (then sending handshake failure).
Works:
$ openssl s_client -connect my.working.server:443 -ssl3
CONNECTED(00000003)
2414208:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
2414208:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
Fails:
$ openssl s_client -connect my.failing.server:443 -ssl3
CONNECTED(00000003)
2414208:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
Sole difference:
2414208:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
It's getting this alert to be sent that is the problem: I cannot seem to find a reference to it anywhere in the Apache documentation.
A .NET client is defaulting to using SSLv3 and it won't retry with a supported SSL version without receiving an alert before a failure.
That's not how SSL protocol negotiation works. The client announces the best version it is willing to support and the server then responds with the best version it can which is equal or lower to the clients version. If this fails some clients (mostly browsers) retry with a lower SSL version because they assume a broken server. But they use a new TCP connection for this, i.e. no kind of renegotiation inside the existing connection.
There is no such thing as a protocol upgrade, which is what you describe here.
TLS 1.0 needed to be enabled on the server for it to send an alert before a failure. The .NET client receives the alert, and tries again with a secure protocol i.e. not SSLv3.