I am using WSO2 API Manager (which support every TLS version) to communicate with TLSv1.1 service. This SSL handshake happens like this.
Client(APIM) Hello TLSv1.2
Server Hello TLSv1.1
handshake successful which is expected.
Then i change the backend service to TLSv1.2 and the handshake fails as below.
Client(APIM) Hello TLSv1.1
Handshake fails.
Here, the APIM initiates the Client Hello with TLSv1.1 based on previous knowledge that the server is using TLSv1.1 . But, since the server is now upgraded to TLSv1.2, it rejects communicating with APIM which is TLSv1.1 .
This is acceptable. Since it is unlikely that the backend service is changing its TLS version on the fly. But if i try after 30 minutes idle time, APIM initiates Client Hello with TLSv1.2 and Server Hello with TLSv1.2 therefore, succesfull handshake.
My assumption is this happens because after around 30 minutes, APIM's SSL session gets timeout. What i want to know is this exact timeout value.
I have tried every timeout value in the configuration files in both APIM and its tomcat.
Thanks in advance
Related
The protocol in question is the MRCP v2 protocol.
Problem overview:
The client sends MRCP/TLS requests, and the server can't understand these since it doesn't have the ability to perform a TLS handshake or encryption. I am hoping that HAProxy, or any other proxy (Nginx?) will decrypt these TLS packets, and send it to the server, to which the server can respond, and then HAProxy can encrypt and send it back to the client.
If possible, I also want a way to extend this to the SIP protocol. From what I understood of HAProxy, it can't do TLS termination for TCP (layer 4), only HTTP (layer 7). Is there any work around/alternative to this?
You are looking for NGINX and its ngx_stream_ssl_module. It allows you to encrypt arbitrary TCP traffic (doesn't have to be HTTP). No special installation is required. Just install NGINX and front it to your server instead of HAProxy or whatever TLS terminator. Configuration is straightforward:
stream {
...
server {
listen 12345 ssl;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
ssl_certificate /usr/local/nginx/conf/cert.pem;
ssl_certificate_key /usr/local/nginx/conf/cert.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
...
}
}
Client -> NGINX (stream TLS termination) -> whichever TCP protocol.
NGINX will only do TLS encryption without inspecting the underlying protocol.
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?
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.
To enable SSL/TLS protocols I had updated tls-default.conf file with "enabledProtocols=TLSv1.2"entry. And also add wrapper.java.additional.=-Djavax.net.debug=ssl to enable SSL debugging.
After running Mule I got the logs mentioned below:
ClientHello, TLSv1
RandomCookie:...
..
ServerHello, TLSv1
From the above logs it is clear that TLSv1 is used instead of TLSv1.2
I am using Mule Version 3.5.2
And JDK 7 which has SunJSSE security provider which allows (PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) protocols.
Is there any way to find out the enabled protocols apart from looking into SSL Handshake logs?