stunnel server configuration requirement to handle CBC protection
Hi, Having recently used stunnel on the phone as a server to encrypt the communication between an external client and a simple TCP server socket on the phone, one of the clients have raised the following.... Phone resets a TLS conection from client, when CBC protection is enabled on tomcat server. The phone syslog shows: Oct 28 14:26:14 10 user.crit syslog: CommsChannelExtenderRx(28881): ./src/CommsChannelExtenderRx.cpp:186 Header section invalid To prevent a SSL/TLS BEAST attack (CVE-2011-3389) Oracle Java (JSSE) has implemented a CBC protection which can be set with System Property jsse.enableCBCProtection. The default value is true. What was done: Start client and connect it with a phone. The TLS connection is established, but then the phone resets the connection, and client is not working. When I set jsse.enableCBCProtection to false at the tomcat server, the phone accepts the connection and client is working. To prevent man-in-the-middle attacks, the phone should be able to handle the fragmented TLS block when CBC protection is activated on the client tomcat server. I have been unable to find the appropriate stunnel configuration item to support this. Please could you inform me how this is handled through stunnel. Thank you for your assistance and I look forward to your responses. Thanks.. John John Simner BSc(Hons) MSc CEng. MIET Software Engineer Unify Enterprise Communications Ltd. Devices Development K Block, Technology Drive, Beeston, Nottingham, NG9 1LA Tel.: +44 (0) 19088 17378 Email: john.simner@unify.com <mailto:vorname.name@unify.com> www.unify.co.uk<http://www.unify.co.uk/> Follow us: [Social_media_icons] <http://www.unify.com/social-media> Unify Enterprise Communications Limited. Registered Office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ Registered No: 5903714, England. This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee then any distribution, copying, or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email.
2013/11/4 Simner, John <john.simner@unify.com>
Hi,
Having recently used stunnel on the phone as a server to encrypt the communication between an external client and a simple TCP server socket on the phone, one of the clients have raised the following….
Phone resets a TLS conection from client, when CBC protection is enabled on tomcat server.
The phone syslog shows: Oct 28 14:26:14 10 user.crit syslog: CommsChannelExtenderRx(28881): ./src/CommsChannelExtenderRx.cpp:186 Header section invalid
To prevent a SSL/TLS BEAST attack (CVE-2011-3389) Oracle Java (JSSE) has implemented a CBC protection which can be set with System Property jsse.enableCBCProtection. The default value is true.
What was done:
Start client and connect it with a phone. The TLS connection is established, but then the phone resets the connection, and client is not working.
When I set jsse.enableCBCProtection to false at the tomcat server, the phone accepts the connection and client is working.
To prevent man-in-the-middle attacks, the phone should be able to handle the fragmented TLS block when CBC protection is activated on the client tomcat server.
I have been unable to find the appropriate stunnel configuration item to support this.
Please could you inform me how this is handled through stunnel.
Thank you for your assistance and I look forward to your responses.
It is really unclear from your e-mail what is connecting to what. First you state that you use stunnel as a server on a phone and something connects to it. Then you describe a Tomcat server and something that looks like a bug report that a phone is unable to connect to this Tomcat server. It is really unclear what is your configuration and what is trying to connect to stunnel and where does a Tomcat server sit in this setup. Please provide accurate and detailed description of your setup, maybe then someone will be able to help. -- Janusz Dziemidowicz
Dear Janusz, Apologies for unclear information in my previous posting. The setup is... Phone Stunnel Client TCP server <----- TLS Server <----- Java based Client (HTTPS protocol) (Simple socket) Sets up new TCP connection -----> TLS Server -----> with tomcat server. I have also requested more information from the developers of the Java based Client. I had simply pasted the information from their fault report. Apologies for any confusion. Look forward to your response. Thanks.. John -----Original Message----- From: Janusz Dziemidowicz [mailto:rraptorr@nails.eu.org] Sent: 05 November 2013 10:21 To: Simner, John Cc: stunnel-users@stunnel.org Subject: Re: [stunnel-users] stunnel server configuration requirement to handle CBC protection 2013/11/4 Simner, John <john.simner@unify.com>
Hi,
Having recently used stunnel on the phone as a server to encrypt the communication between an external client and a simple TCP server socket on the phone, one of the clients have raised the following….
Phone resets a TLS conection from client, when CBC protection is enabled on tomcat server.
The phone syslog shows: Oct 28 14:26:14 10 user.crit syslog: CommsChannelExtenderRx(28881): ./src/CommsChannelExtenderRx.cpp:186 Header section invalid
To prevent a SSL/TLS BEAST attack (CVE-2011-3389) Oracle Java (JSSE) has implemented a CBC protection which can be set with System Property jsse.enableCBCProtection. The default value is true.
What was done:
Start client and connect it with a phone. The TLS connection is established, but then the phone resets the connection, and client is not working.
When I set jsse.enableCBCProtection to false at the tomcat server, the phone accepts the connection and client is working.
To prevent man-in-the-middle attacks, the phone should be able to handle the fragmented TLS block when CBC protection is activated on the client tomcat server.
I have been unable to find the appropriate stunnel configuration item to support this.
Please could you inform me how this is handled through stunnel.
Thank you for your assistance and I look forward to your responses.
It is really unclear from your e-mail what is connecting to what. First you state that you use stunnel as a server on a phone and something connects to it. Then you describe a Tomcat server and something that looks like a bug report that a phone is unable to connect to this Tomcat server. It is really unclear what is your configuration and what is trying to connect to stunnel and where does a Tomcat server sit in this setup. Please provide accurate and detailed description of your setup, maybe then someone will be able to help. -- Janusz Dziemidowicz
2013/11/5 Simner, John <john.simner@unify.com>:
Dear Janusz, Apologies for unclear information in my previous posting.
The setup is...
Phone Stunnel Client TCP server <----- TLS Server <----- Java based Client (HTTPS protocol) (Simple socket) Sets up new TCP connection -----> TLS Server -----> with tomcat server.
I have also requested more information from the developers of the Java based Client. I had simply pasted the information from their fault report.
Apologies for any confusion. Look forward to your response.
Just to be sure: Java HTTPS client connects to stunnel (working in server mode; it decrypts traffic) which connects to a pure TCP server which connects to another instance of stunnel (in client mode; it encrypts traffic) which connects to Tomcat server using HTTPS, right? Unfortunately in this setup jsse.enableCBCProtection is completely meaningless on Tomcat server. jsse.enableCBCProtection is a client side setting, which means that it only affects Java HTTPS clients, not Java HTTPS servers. So it should make no difference at all on Tomcat.
From your description the problem is between stunnel in client mode and Tomcat server, so this setting is not the cause of problems. On the other hand jsse.enableCBCProtection is known to be broken in certain Java versions: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7103725
-- Janusz Dziemidowicz
Dear Janusz, Thank you for your email and the information. I forwarded it to the person raising the problem and I received the following response... - On the tomcat PC there is the latest java version running, 1.7.0.45. The link below mentioned 1.6.0.26 and 29 as broken, and fixed with 1.6.0.30. - The simple setup is... PC (running Web Browser) -> PC connects to tomcat server using TCP and starts jHPT (the Java based client) on tomcat. In this simple setup I'm using TCP, not TLS, between PC and tomcat. -> jHPT (tomcat) connects to phone using TLS -> stunnel on phone (in server mode) accepts the TLS connection (tomcat is the client for this TLS connection). If I set in the tomcat config the java parameter -Djsse.enableCBCProtection=false, the connection between tomcat and phone (stunnel) is stable. If I set in the tomcat config the java parameter -Djsse.enableCBCProtection=true, the phone (stunnel) resets the connection. I hope this clarifies what is happening between the client and stunnel on the phone. Within the phone, stunnel connects to the TCP server which then sets up a new connection back to stunnel/client. So, is there a problem in stunnel or do I need to investigate what is being received between stunnel and the TCP server/TCP connection on the phone. Once again, thank you for your assistance and I look forward to your response. Thanks.. John -----Original Message----- From: Janusz Dziemidowicz [mailto:rraptorr@nails.eu.org] Sent: 05 November 2013 10:59 To: Simner, John Cc: stunnel-users@stunnel.org Subject: Re: [stunnel-users] stunnel server configuration requirement to handle CBC protection 2013/11/5 Simner, John <john.simner@unify.com>:
Dear Janusz, Apologies for unclear information in my previous posting.
The setup is...
Phone Stunnel Client TCP server <----- TLS Server <----- Java based Client (HTTPS protocol) (Simple socket) Sets up new TCP connection -----> TLS Server -----> with tomcat server.
I have also requested more information from the developers of the Java based Client. I had simply pasted the information from their fault report.
Apologies for any confusion. Look forward to your response.
Just to be sure: Java HTTPS client connects to stunnel (working in server mode; it decrypts traffic) which connects to a pure TCP server which connects to another instance of stunnel (in client mode; it encrypts traffic) which connects to Tomcat server using HTTPS, right? Unfortunately in this setup jsse.enableCBCProtection is completely meaningless on Tomcat server. jsse.enableCBCProtection is a client side setting, which means that it only affects Java HTTPS clients, not Java HTTPS servers. So it should make no difference at all on Tomcat. From your description the problem is between stunnel in client mode and Tomcat server, so this setting is not the cause of problems. On the other hand jsse.enableCBCProtection is known to be broken in certain Java versions: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7103725 -- Janusz Dziemidowicz
2013/11/5 Simner, John <john.simner@unify.com>:
Dear Janusz, Thank you for your email and the information. I forwarded it to the person raising the problem and I received the following response...
- On the tomcat PC there is the latest java version running, 1.7.0.45. The link below mentioned 1.6.0.26 and 29 as broken, and fixed with 1.6.0.30.
- The simple setup is...
PC (running Web Browser) -> PC connects to tomcat server using TCP and starts jHPT (the Java based client) on tomcat. In this simple setup I'm using TCP, not TLS, between PC and tomcat. -> jHPT (tomcat) connects to phone using TLS -> stunnel on phone (in server mode) accepts the TLS connection (tomcat is the client for this TLS connection).
If I set in the tomcat config the java parameter -Djsse.enableCBCProtection=false, the connection between tomcat and phone (stunnel) is stable.
If I set in the tomcat config the java parameter -Djsse.enableCBCProtection=true, the phone (stunnel) resets the connection.
I hope this clarifies what is happening between the client and stunnel on the phone. Within the phone, stunnel connects to the TCP server which then sets up a new connection back to stunnel/client.
So, is there a problem in stunnel or do I need to investigate what is being received between stunnel and the TCP server/TCP connection on the phone.
Once again, thank you for your assistance and I look forward to your response.
I am sorry, but I will not provide support for your company customers. If you are just going to forward my replies to your customers and theirs to me this will not work and I am not going to provide any more help. I have explained to you what this JSSE option does. stunnel uses OpenSSL for SSL implementation and there are no special options to support 0/n or 1/n-1 record splitting (the CBC protection), it will happily accept both. I really have no idea where the problem is since your description is again vague. Please debug your own application yourself and establish if the problem is between Java client and stunnel or between stunnel and Tomcat server. I am unable to do this, you must do this yourself. Capturing network traffic with packet sniffer is usually a very good tool for debugging such problems. -- Janusz Dziemidowicz
Can I just ask - is there no way to simply exclude the vulnerable CBC-based ciphers during the stunnel startup, so that when the client connects, there will never be a successful negotiation to use one of them? That's how I fix it on our load balancers, set them to require e.g. RC4-SHA (actually, I have a preferred order, with TLS1.2 ciphers preferred, but fallback to RC4-SHA for clients that don't support TLS1.2, which is most - see https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-be... for more info). -----Original Message----- From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Janusz Dziemidowicz Sent: Tuesday, November 05, 2013 8:03 AM To: Simner, John Cc: stunnel-users@stunnel.org Subject: EXTERNAL: Re: [stunnel-users] stunnel server configuration requirement to handle CBC protection 2013/11/5 Simner, John <john.simner@unify.com>:
Dear Janusz, Thank you for your email and the information. I forwarded it to the person raising the problem and I received the following response...
- On the tomcat PC there is the latest java version running, 1.7.0.45. The link below mentioned 1.6.0.26 and 29 as broken, and fixed with 1.6.0.30.
- The simple setup is...
PC (running Web Browser) -> PC connects to tomcat server using TCP and starts jHPT (the Java based client) on tomcat. In this simple setup I'm using TCP, not TLS, between PC and tomcat. -> jHPT (tomcat) connects to phone using TLS -> stunnel on phone (in server mode) accepts the TLS connection (tomcat is the client for this TLS connection).
If I set in the tomcat config the java parameter -Djsse.enableCBCProtection=false, the connection between tomcat and phone (stunnel) is stable.
If I set in the tomcat config the java parameter -Djsse.enableCBCProtection=true, the phone (stunnel) resets the connection.
I hope this clarifies what is happening between the client and stunnel on the phone. Within the phone, stunnel connects to the TCP server which then sets up a new connection back to stunnel/client.
So, is there a problem in stunnel or do I need to investigate what is being received between stunnel and the TCP server/TCP connection on the phone.
Once again, thank you for your assistance and I look forward to your response.
I am sorry, but I will not provide support for your company customers. If you are just going to forward my replies to your customers and theirs to me this will not work and I am not going to provide any more help. I have explained to you what this JSSE option does. stunnel uses OpenSSL for SSL implementation and there are no special options to support 0/n or 1/n-1 record splitting (the CBC protection), it will happily accept both. I really have no idea where the problem is since your description is again vague. Please debug your own application yourself and establish if the problem is between Java client and stunnel or between stunnel and Tomcat server. I am unable to do this, you must do this yourself. Capturing network traffic with packet sniffer is usually a very good tool for debugging such problems. -- Janusz Dziemidowicz _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
2013/11/5 Bucci, David G <david.g.bucci@lmco.com>:
Can I just ask - is there no way to simply exclude the vulnerable CBC-based ciphers during the stunnel startup, so that when the client connects, there will never be a successful negotiation to use one of them? That's how I fix it on our load balancers, set them to require e.g. RC4-SHA (actually, I have a preferred order, with TLS1.2 ciphers preferred, but fallback to RC4-SHA for clients that don't support TLS1.2, which is most - see https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-be... for more info).
This is not a good solution. Unfortunately, with the current state of software there are no good solutions [1]: - the real and proper solution is to use only TLS 1.1/1.2 and disable TLS 1.0 - but most implementations do not support TLS1.1/1.2 at all - another you have mentioned is preferring RC4... but RC4 was found to be quite broken; in fact RC4 is now considered probably more vulnerable than BEAST itself [2] - mitigating the threat on the client side by record splitting (either 0/n or 1/n-1) - but this can be done only on the client side due to the way BEAST works For this reason Qualys, that you have referenced, now considers having RC4 a worse thing that being vulnerable to BEAST. BEAST is mitigated on the client (browser) side [3] so it is now generally advised to disable RC4 completely [4] [5]. On the other hand, please note how does BEAST attack work. It requires attacker to be able to send arbitrary data from the victim to the server. This is true in case of a browser (custom Java applet was used for this purpose in original BEAST attack). But this might not be true if TLS is used for traffic different than HTTP. Unfortunately it is unclear what kind of traffic is passed between the phone and client in this particular case. It is possible that this particular scenario is not vulnerable to BEAST attack at all. In such case preferring RC4 will just lower the security without fixing anything. Do remember to properly evaluate any potential vulnerabilities and if they apply to given case as blindly following any, otherwise correct, workarounds might cause more harm. [1] https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-bro... [2] https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-... [3] https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-bea... [4] https://community.qualys.com/blogs/securitylabs/2013/09/17/updated-ssltls-de... [5] http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01 -- Janusz Dziemidowicz
Hmm. I had heard some of this but not gotten to studying it in better detail, thx. Unfortunately, our security posture is dictated to us, and deprecating CBC is active guidance, where I haven't seen any guidance yet on RC4 ... but that could change any day. I do wonder, though, at the strength of that recommendation to revert to CBCs ... BEAST and CRIME and Lucky13 have actual, working attack software known to be in use, no? And I'm not dismissing it, but the attack vector seems more limiting for an RC4 vulnerability - millions of hits during the session using different keys + known string, all having to be run from within your browser/client context. Maybe a better posture would be, prefer CBCs for TLS1.1/1.2, but if falling back to TLS1.0/SSL3.0, use RC4. No? I think some of my network devices have that flexibility - not sure about OpenSSL, if you can control based on protocol. In any case, back to the root question - is it possible to config stunnel to pass the cipher limitations/preferences to OpenSSL? p.s. I AM considering stuffing a few hundred bytes of meaningless, random headers into some of my apps' returns, however, as a quick fix. At least move the problem to the right on the probability graph. -----Original Message----- From: Janusz Dziemidowicz [mailto:rraptorr@nails.eu.org] Sent: Tuesday, November 05, 2013 2:59 PM To: Bucci, David G Cc: Simner, John; stunnel-users@stunnel.org Subject: Re: EXTERNAL: Re: [stunnel-users] stunnel server configuration requirement to handle CBC protection 2013/11/5 Bucci, David G <david.g.bucci@lmco.com>:
Can I just ask - is there no way to simply exclude the vulnerable CBC-based ciphers during the stunnel startup, so that when the client connects, there will never be a successful negotiation to use one of them? That's how I fix it on our load balancers, set them to require e.g. RC4-SHA (actually, I have a preferred order, with TLS1.2 ciphers preferred, but fallback to RC4-SHA for clients that don't support TLS1.2, which is most - see https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-be... for more info).
This is not a good solution. Unfortunately, with the current state of software there are no good solutions [1]: - the real and proper solution is to use only TLS 1.1/1.2 and disable TLS 1.0 - but most implementations do not support TLS1.1/1.2 at all - another you have mentioned is preferring RC4... but RC4 was found to be quite broken; in fact RC4 is now considered probably more vulnerable than BEAST itself [2] - mitigating the threat on the client side by record splitting (either 0/n or 1/n-1) - but this can be done only on the client side due to the way BEAST works For this reason Qualys, that you have referenced, now considers having RC4 a worse thing that being vulnerable to BEAST. BEAST is mitigated on the client (browser) side [3] so it is now generally advised to disable RC4 completely [4] [5]. On the other hand, please note how does BEAST attack work. It requires attacker to be able to send arbitrary data from the victim to the server. This is true in case of a browser (custom Java applet was used for this purpose in original BEAST attack). But this might not be true if TLS is used for traffic different than HTTP. Unfortunately it is unclear what kind of traffic is passed between the phone and client in this particular case. It is possible that this particular scenario is not vulnerable to BEAST attack at all. In such case preferring RC4 will just lower the security without fixing anything. Do remember to properly evaluate any potential vulnerabilities and if they apply to given case as blindly following any, otherwise correct, workarounds might cause more harm. [1] https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-bro... [2] https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-... [3] https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-bea... [4] https://community.qualys.com/blogs/securitylabs/2013/09/17/updated-ssltls-de... [5] http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01 -- Janusz Dziemidowicz
2013/11/5 Bucci, David G <david.g.bucci@lmco.com>:
Hmm. I had heard some of this but not gotten to studying it in better detail, thx. Unfortunately, our security posture is dictated to us, and deprecating CBC is active guidance, where I haven't seen any guidance yet on RC4 ... but that could change any day.
Well, RC4 being broken was covered quite broadly this year in various places. If you have such policy then it really should be reviewed at least yearly (if not often) based on current research. Following all current cryptography work is a must if you wish to provide serious security;)
I do wonder, though, at the strength of that recommendation to revert to CBCs ... BEAST and CRIME and Lucky13 have actual, working attack software known to be in use, no? And I'm not dismissing it, but the attack vector seems more limiting for an RC4 vulnerability - millions of hits during the session using different keys + known string, all having to be run from within your browser/client context.
Not having a practical attack for RC4 is not an excuse. Theoretical work for BEAST was known for a number of years before BEAST was developed and you have no guarantee that somebody did not make it earlier. Just consider this: - BEAST is defeated both in theory and practice by using TLS1.1/1.2 - CRIME is defeated, again both in theory and practice by disabling compression - Lucky13 was fixed in OpenSSL code at least - you have a theoretical weakness in RC4 with no known workaround or fix The choice is yours. It also depends on your threat model. Are you just trying to make impossible to sniff your users passwords on a shared Wi-Fi or are you working for Google and trying to defeat NSA. Quite a few things depend on answer to this question.
Maybe a better posture would be, prefer CBCs for TLS1.1/1.2, but if falling back to TLS1.0/SSL3.0, use RC4. No? I think some of my network devices have that flexibility - not sure about OpenSSL, if you can control based on protocol.
This is flawed. Making downgrade attack, forcing your target to use TLS 1.0 (and thus RC4) is trivial.
In any case, back to the root question - is it possible to config stunnel to pass the cipher limitations/preferences to OpenSSL?
This is basic configuration easily found in man page: https://www.stunnel.org/static/stunnel.html
p.s. I AM considering stuffing a few hundred bytes of meaningless, random headers into some of my apps' returns, however, as a quick fix. At least move the problem to the right on the probability graph.
That will make absolute no difference for BEAST. It might make CRIME harder (but disabling compression is best bet if you prefer security over performance). -- Janusz Dziemidowicz
On 2013-11-04 18:12, Simner, John wrote:
To prevent man-in-the-middle attacks, the phone should be able to handle the fragmented TLS block when CBC protection is activated on the client tomcat server.
I have been unable to find the appropriate stunnel configuration item to support this.
Please could you inform me how this is handled through stunnel.
There is no option to *enable* CBC protection, as this is the default. Use "options = DONT_INSERT_EMPTY_FRAGMENTS" to disable this secure default. Mike
participants (4)
-
Bucci, David G -
Janusz Dziemidowicz -
Michal Trojnara -
Simner, John