Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tim, On 3/3/13 4:18 PM, Tim Whittington wrote: > On Tue, Feb 19, 2013 at 10:59 AM, Giuseppe Sacco > wrote: [...] > >> I listed all providers here: >> http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphers-no-bouncycastle.html >> >> as you may see, a few of them are TLS_RSA and TLS_DHE: >> * TLS_RSA_WITH_AES_128_CBC_SHA * >> TLS_RSA_WITH_AES_256_CBC_SHA * >> TLS_DHE_DSS_WITH_AES_128_CBC_SHA * >> TLS_DHE_DSS_WITH_AES_256_CBC_SHA * >> TLS_DHE_RSA_WITH_AES_128_CBC_SHA * >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA >> >> They are also listed as "default" ciphers, so -- if I understood >> what default means -- they should not be enabled explicitly. >> >> They overlap with those client ciphers: >> TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA >> TLS_DHE_RSA_WITH_AES_128_CBC_SHA >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA >> >> Is there any possibility that some of those server ciphers are >> disabled because of the algorithm used in the server certificate? >> Its signature algorithm is SHA1withDSA. I created it with this >> command line: keytool -genkeypair -alias tomcat -keystore >> ~tomcat6/.keystore > > Yes. If the server keys are DSA, then only cipher suites using > DSS/*DSA will be negotiated. In this case, the only DSS cipher > suite that your client appears to support is > TLS_DHE_DSS_WITH_NULL_SHA, which isn't supported by Java 6 or 7. Good catch. I recently tried to get a DSA key to work *at all* with Apache httpd and I simply could not. I didn't try too hard, honestly, because I didn't really care. My recommendation would be to stick with an RSA key unless you have some specific reason not to use one (and I'd like to hear that reason). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlE1QFIACgkQ9CaO5/Lv0PCdOQCdFA1+Yp3tgWYuzZp39wndEwyF aUkAmgLH2S+B6sH/ilgAJkCSsSTI/2xm =JDLH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
On Tue, Feb 19, 2013 at 10:59 AM, Giuseppe Sacco wrote: [...] > I listed all providers here: > http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphers-no-bouncycastle.html > as you may see, a few of them are TLS_RSA and TLS_DHE: > * TLS_RSA_WITH_AES_128_CBC_SHA > * TLS_RSA_WITH_AES_256_CBC_SHA > * TLS_DHE_DSS_WITH_AES_128_CBC_SHA > * TLS_DHE_DSS_WITH_AES_256_CBC_SHA > * TLS_DHE_RSA_WITH_AES_128_CBC_SHA > * TLS_DHE_RSA_WITH_AES_256_CBC_SHA > > They are also listed as "default" ciphers, so -- if I understood what > default means -- they should not be enabled explicitly. > > They overlap with those client ciphers: > TLS_RSA_WITH_AES_128_CBC_SHA > TLS_RSA_WITH_AES_256_CBC_SHA > TLS_DHE_RSA_WITH_AES_128_CBC_SHA > TLS_DHE_RSA_WITH_AES_256_CBC_SHA > > Is there any possibility that some of those server ciphers are disabled > because of the algorithm used in the server certificate? Its signature > algorithm is SHA1withDSA. I created it with this command line: > keytool -genkeypair -alias tomcat -keystore ~tomcat6/.keystore Yes. If the server keys are DSA, then only cipher suites using DSS/*DSA will be negotiated. In this case, the only DSS cipher suite that your client appears to support is TLS_DHE_DSS_WITH_NULL_SHA, which isn't supported by Java 6 or 7. > A side note: is it possibile to put tomcat behind a web server and make > the latter encrypt in SSL? This would imply that communication between > the web server and tomcat would be in clear, but how do I create the > connector proxy* information? I may specify proxyName and proxyPort, but > I cannot specify proxyProtocol. Is this right? > tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
On 18.02.2013 22:59, Giuseppe Sacco wrote: > A side note: is it possibile to put tomcat behind a web server and make > the latter encrypt in SSL? This would imply that communication between > the web server and tomcat would be in clear, but how do I create the > connector proxy* information? I may specify proxyName and proxyPort, but > I cannot specify proxyProtocol. Is this right? Look for "scheme" and for "secure" in https://tomcat.apache.org/tomcat-7.0-doc/config/http.html Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Hi Martin, Il giorno ven, 15/02/2013 alle 18.29 -0500, Martin Gainty ha scritto: > someone put cipherSuites patch on TC 7 Connector.. > > *IF you are implementing TC7 Connector with cipherSuites attribute support > and have not specified cipherSuites supported by your ppk keys* > then yes its tomcats fault I am using 6.0.36. Bye, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Hi Cris, Il giorno ven, 15/02/2013 alle 12.36 -0500, Christopher Schultz ha scritto: [...] > > Allow legacy hello messages: true [snip] http-192.168.1.55-8443-1, > > READ: SSLv3 Handshake, length = 75 *** ClientHello, SSLv3 > > RandomCookie: GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77, > > 52, 134, 4, 76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47, > > 219, 81, 28, 23, 174, 156 } Session ID: {} Cipher Suites: > > [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown > > 0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, > > SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA, > > SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b, > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, > > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b, > > SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5] Compression Methods: > > { 0 } *** > > So the client is doing an SSLv3 handshake. The message above about > allowing legacy "hellos" seems like it should support a SSLv3 > handshake. Looking at the ciphers, your JVM (without BouncyCastle) and > client truly have no overlap. I'm actually surprised that your JVM > does not support any TLS_RSA_* or TLS_DHE_* ciphers. Can you re-run my > cipher-dump program without BouncyCastle and provide the full output? > I was a little unclear as to what you posted last time. I listed all providers here: http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphers-no-bouncycastle.html as you may see, a few of them are TLS_RSA and TLS_DHE: * TLS_RSA_WITH_AES_128_CBC_SHA * TLS_RSA_WITH_AES_256_CBC_SHA * TLS_DHE_DSS_WITH_AES_128_CBC_SHA * TLS_DHE_DSS_WITH_AES_256_CBC_SHA * TLS_DHE_RSA_WITH_AES_128_CBC_SHA * TLS_DHE_RSA_WITH_AES_256_CBC_SHA They are also listed as "default" ciphers, so -- if I understood what default means -- they should not be enabled explicitly. They overlap with those client ciphers: TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA Is there any possibility that some of those server ciphers are disabled because of the algorithm used in the server certificate? Its signature algorithm is SHA1withDSA. I created it with this command line: keytool -genkeypair -alias tomcat -keystore ~tomcat6/.keystore A side note: is it possibile to put tomcat behind a web server and make the latter encrypt in SSL? This would imply that communication between the web server and tomcat would be in clear, but how do I create the connector proxy* information? I may specify proxyName and proxyPort, but I cannot specify proxyProtocol. Is this right? Bye, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
someone put cipherSuites patch on TC 7 Connector.. *IF you are implementing TC7 Connector with cipherSuites attribute support and have not specified cipherSuites supported by your ppk keys* then yes its tomcats fault Otherwise its not.. Ciao, Martin Gainty __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > Date: Fri, 15 Feb 2013 12:36:53 -0500 > From: ch...@christopherschultz.net > To: users@tomcat.apache.org > Subject: Re: Tomcat does not accept connections from Safari on iPad vs an SSL > connector with JSSE ciphers > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Giuseppe, > > On 2/15/13 9:07 AM, Giuseppe Sacco wrote: > > Debugging the SSL handshake, I found that the problem is really > > about ciphers because the handshake fails with exception > > javax.net.ssl.SSLHandshakeException: no cipher suites in common > > > > So, this is really something to be investigated in JSSE instead of > > tomcat. I am sorry for noise in this list :-( > > We were pretty sure it wasn't Tomcat's fault, but we can still > probably help. > > > Allow legacy hello messages: true [snip] http-192.168.1.55-8443-1, > > READ: SSLv3 Handshake, length = 75 *** ClientHello, SSLv3 > > RandomCookie: GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77, > > 52, 134, 4, 76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47, > > 219, 81, 28, 23, 174, 156 } Session ID: {} Cipher Suites: > > [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown > > 0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, > > SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA, > > SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b, > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, > > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b, > > SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5] Compression Methods: > > { 0 } *** > > So the client is doing an SSLv3 handshake. The message above about > allowing legacy "hellos" seems like it should support a SSLv3 > handshake. Looking at the ciphers, your JVM (without BouncyCastle) and > client truly have no overlap. I'm actually surprised that your JVM > does not support any TLS_RSA_* or TLS_DHE_* ciphers. Can you re-run my > cipher-dump program without BouncyCastle and provide the full output? > I was a little unclear as to what you posted last time. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEAREIAAYFAlEecjUACgkQ9CaO5/Lv0PCEnwCdE7P2NRug8jYW+GcdcT2kUB7u > ZGwAoKNBfMMPOQCAm2IATvldiWpaAVrO > =qMlU > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Giuseppe, On 2/15/13 9:07 AM, Giuseppe Sacco wrote: > Debugging the SSL handshake, I found that the problem is really > about ciphers because the handshake fails with exception > javax.net.ssl.SSLHandshakeException: no cipher suites in common > > So, this is really something to be investigated in JSSE instead of > tomcat. I am sorry for noise in this list :-( We were pretty sure it wasn't Tomcat's fault, but we can still probably help. > Allow legacy hello messages: true [snip] http-192.168.1.55-8443-1, > READ: SSLv3 Handshake, length = 75 *** ClientHello, SSLv3 > RandomCookie: GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77, > 52, 134, 4, 76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47, > 219, 81, 28, 23, 174, 156 } Session ID: {} Cipher Suites: > [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown > 0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, > SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA, > SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b, > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b, > SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5] Compression Methods: > { 0 } *** So the client is doing an SSLv3 handshake. The message above about allowing legacy "hellos" seems like it should support a SSLv3 handshake. Looking at the ciphers, your JVM (without BouncyCastle) and client truly have no overlap. I'm actually surprised that your JVM does not support any TLS_RSA_* or TLS_DHE_* ciphers. Can you re-run my cipher-dump program without BouncyCastle and provide the full output? I was a little unclear as to what you posted last time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEecjUACgkQ9CaO5/Lv0PCEnwCdE7P2NRug8jYW+GcdcT2kUB7u ZGwAoKNBfMMPOQCAm2IATvldiWpaAVrO =qMlU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Debugging the SSL handshake, I found that the problem is really about ciphers because the handshake fails with exception javax.net.ssl.SSLHandshakeException: no cipher suites in common So, this is really something to be investigated in JSSE instead of tomcat. I am sorry for noise in this list :-( This is the complete log obtained with -Djavax.net.debug=all: Allow unsafe renegotiation: false Allow legacy hello messages: true Is initial handshake: true Is secure renegotiation: false http-192.168.1.55-8443-1, setSoTimeout(6) called [Raw read]: length = 5 : 16 03 00 00 4B K [Raw read]: length = 75 : 01 00 00 47 03 00 51 1E 33 5C CB 56 A8 58 4B 4D ...G..Q.3\.V.XKM 0010: 34 86 04 4C CC 4E 00 A0 A8 7B 60 4E 6A 17 28 2F 4..L.N`Nj.(/ 0020: DB 51 1C 17 AE 9C 00 00 20 00 FF 00 3D 00 3C 00 .Q.. ...=.<. 0030: 2F 00 05 00 04 00 35 00 0A 00 67 00 6B 00 33 00 /.5...g.k.3. 0040: 39 00 16 00 3B 00 02 00 01 01 00 9...;.. http-192.168.1.55-8443-1, READ: SSLv3 Handshake, length = 75 *** ClientHello, SSLv3 RandomCookie: GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77, 52, 134, 4, 76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47, 219, 81, 28, 23, 174, 156 } Session ID: {} Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown 0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b, SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5] Compression Methods: { 0 } *** [read] MD5 and SHA1 hashes: len = 75 : 01 00 00 47 03 00 51 1E 33 5C CB 56 A8 58 4B 4D ...G..Q.3\.V.XKM 0010: 34 86 04 4C CC 4E 00 A0 A8 7B 60 4E 6A 17 28 2F 4..L.N`Nj.(/ 0020: DB 51 1C 17 AE 9C 00 00 20 00 FF 00 3D 00 3C 00 .Q.. ...=.<. 0030: 2F 00 05 00 04 00 35 00 0A 00 67 00 6B 00 33 00 /.5...g.k.3. 0040: 39 00 16 00 3B 00 02 00 01 01 00 9...;.. http-192.168.1.55-8443-1, SEND SSLv3 ALERT: fatal, description = handshake_failure http-192.168.1.55-8443-1, WRITE: SSLv3 Alert, length = 2 [Raw write]: length = 7 : 15 03 00 00 02 02 28 ..( http-192.168.1.55-8443-1, called closeSocket() http-192.168.1.55-8443-1, handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common http-192.168.1.55-8443-1, called close() http-192.168.1.55-8443-1, called closeInternal(true) Finalizer, called close() Finalizer, called closeInternal(true) Finalizer, called close() Finalizer, called closeInternal(true) Finalizer, called close() Finalizer, called closeInternal(true) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Il giorno ven, 15/02/2013 alle 09.39 +0100, Giuseppe Sacco ha scritto: > [...] > > > > > maxThreads="150" scheme="https" secure="true" clientAuth="false" > > > sslProtocol="TLS" proxyName="www.my-visible-name.tld" > > > proxyPort="8443" address="192.168.1.55" /> > > > > It's traditional to specify a server key and certificate when > > configuring SSL. Where are yours configured? > > I used default values: the keystore in named ".keystore" and is in the > home directory of the user running tomcat. It contains only one key pair > and one certificate, and its password is the standard one. A complete log from ssldump when connecting with safari on iPad is here (http://centrum.lixper.it/~giuseppe/ipad-ssl-problem-with-tomcat.html). I start thinking this is not a problem of cipher, but of protocol version. In fact, I checked the complete list of available ciphers (http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphes.html) and there are a few matching. Should I try changing the `sslProtocol` from `TLS` so some `SSLv?`. Thanks, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Il giorno gio, 14/02/2013 alle 11.38 -0500, Christopher Schultz ha scritto: [...] > > Tomcat version is the one shipped with Debian, and uses jdk > > 1.6.0_u39 with jce unrestricted policy. I also added bouncy castle > > jar in $JAVA_HOME/jre/lib/ext and added its provider in > > $JAVA_HOME/jre/lib/security/java.security as last in the provider > > list. After restarting tomcat nothing changed. > > Did you add Bouncy Castle just to see if it would improve things? Or > are you attempting to use Bouncy Castle as your provider? I added it in oder to add moe ciphes. I don't even know if this new povider is used at all. The only step I did are the one listed above. [...] > > > maxThreads="150" scheme="https" secure="true" clientAuth="false" > > sslProtocol="TLS" proxyName="www.my-visible-name.tld" > > proxyPort="8443" address="192.168.1.55" /> > > It's traditional to specify a server key and certificate when > configuring SSL. Where are yours configured? I used default values: the keystore in named ".keystore" and is in the home directory of the user running tomcat. It contains only one key pair and one certificate, and its password is the standard one. > > So, my question: how to configure tomcat for accepting a broader > > range of ciphers, or at least to accept even one of those used by > > this browser? > > The default cipher suite depends upon your JVM, and is usually fairly > inclusive. Here's a little program I wrote to find out what your JVM > will support and what its default cipher suite will be: > http://markmail.org/message/zn4namfhypyxum23 Right. This is why I added bouncycastle. Anyway, I just tried the program in the link you supplied. This is its output: /tmp# java -showversion SSLInfo java version "1.6.0_39" Java(TM) SE Runtime Environment (build 1.6.0_39-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode) Default Cipher * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA * SSL_DHE_DSS_WITH_DES_CBC_SHA * SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA * SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 * SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * SSL_RSA_EXPORT_WITH_RC4_40_MD5 * SSL_RSA_WITH_3DES_EDE_CBC_SHA * SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA * SSL_RSA_WITH_RC4_128_MD5 * SSL_RSA_WITH_RC4_128_SHA * TLS_DHE_DSS_WITH_AES_128_CBC_SHA * TLS_DHE_DSS_WITH_AES_256_CBC_SHA * TLS_DHE_RSA_WITH_AES_128_CBC_SHA * TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA * TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_NULL_SHA * TLS_ECDHE_ECDSA_WITH_RC4_128_SHA * TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_NULL_SHA * TLS_ECDHE_RSA_WITH_RC4_128_SHA * TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA * TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_NULL_SHA * TLS_ECDH_ECDSA_WITH_RC4_128_SHA * TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDH_RSA_WITH_AES_128_CBC_SHA * TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_NULL_SHA * TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_NULL_SHA TLS_ECDH_anon_WITH_RC4_128_SHA * TLS_EMPTY_RENEGOTIATION_INFO_SCSV TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA TLS_KRB5_EXPORT_WITH_RC4_40_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_SHA TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_3DES_EDE_CBC_SHA TLS_KRB5_WITH_DES_CBC_MD5 TLS_KRB5_WITH_DES_CBC_SHA TLS_KRB5_WITH_RC4_128_MD5 TLS_KRB5_WITH_RC4_128_SHA * TLS_RSA_WITH_AES_128_CBC_SHA * TLS_RSA_WITH_AES_256_CBC_SHA If I run it after removing the bouncy castle provider, this list become short. The diff is about ciphers that iPad does not use, so I think I may remove bouncy castle at all: < * TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA < * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA < * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA < TLS_ECDHE_ECDSA_WITH_NULL_SHA < * TLS_ECDHE_ECDSA_WITH_RC4_128_SHA < * TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA < * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA < * TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA < TLS_ECDHE_RSA_WITH_NULL_SHA < * TLS_ECDHE_RSA_WITH_RC4_
RE: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Tomcat by default should accept all the enabled cipher suites in an SSLSocket, unless it has been configured to do differently. That list is far longer than either of the client lists supplied. -Original Message- From: Giuseppe Sacco [mailto:giuse...@eppesuigoccas.homedns.org] Sent: Thursday, 14 February 2013 8:48 AM To: users@tomcat.apache.org Subject: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers Hi all, I have an application deployed on tomcat 6.0.35 and linux/amd64 with a JSSE https connector. When I try to connect to this site with default iPad browser, I always get an error message about the connection cannot be established. Tomcat version is the one shipped with Debian, and uses jdk 1.6.0_u39 with jce unrestricted policy. I also added bouncy castle jar in $JAVA_HOME/jre/lib/ext and added its provider in $JAVA_HOME/jre/lib/security/java.security as last in the provider list. After restarting tomcat nothing changed. I used the command line tool "ssldump" to check what happens and it seems the problem is in the cipher suite used by iPad: none of the ciphers is accepted by the server. This is what ssldump command show: New TCP connection #1: host35-105-static.24-87-b.business.telecomitalia.it(59049) <-> 192.168.1.55(8443) 1 1 0.0979 (0.0979) C>S Handshake ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_NULL_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_MD5 compression methods NULL iPad does try a few times, changing the version number, but it fails every time and eventually stop. When connecting using Chrome on the very same iPad, the connection works. The relevant dump is: New TCP connection #1: host35-105-static.24-87-b.business.telecomitalia.it(59049) <-> 192.168.1.55(8443) 1 1 0.0979 (0.0979) C>S Handshake ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_NULL_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_MD5 compression methods NULL Ths cipher accepted by the server is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA The connector I use is: This is a JSSE connector since it display this message in log file: 13-feb-2013 12.57.49 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-192.168.1.55-8443 So, my question: how to configure tomcat for accepting a broader range of ciphers, or at least to accept even one of those used by this browser? Thank you very much, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
On Thu, Feb 14, 2013 at 11:38 AM, Christopher Schultz wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Giuseppe, > > On 2/13/13 4:47 PM, Giuseppe Sacco wrote: > > > > iPad does try a few times, changing the version number, but it > > fails every time and eventually stop. > > > > When connecting using Chrome on the very same iPad, the connection > > works. > > Wow, I had no idea that Google Chrome was available for iOS. Cool! > Yep, I forced/asked the endusers of my web app (my family) to use Google Chrome on any all devices, Android, iPad (my father's iPad), and Windows 7 laptops. :) > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEAREIAAYFAlEdEv8ACgkQ9CaO5/Lv0PCfAgCeIBzGP27N+gbTDAiLRcHOCO5K > T7UAoJSZnWMPmSUpZZIfcE0L9ROaE7UX > =OIY1 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Giuseppe, On 2/13/13 4:47 PM, Giuseppe Sacco wrote: > I have an application deployed on tomcat 6.0.35 and linux/amd64 > with a JSSE https connector. When I try to connect to this site > with default iPad browser, I always get an error message about the > connection cannot be established. > > Tomcat version is the one shipped with Debian, and uses jdk > 1.6.0_u39 with jce unrestricted policy. I also added bouncy castle > jar in $JAVA_HOME/jre/lib/ext and added its provider in > $JAVA_HOME/jre/lib/security/java.security as last in the provider > list. After restarting tomcat nothing changed. Did you add Bouncy Castle just to see if it would improve things? Or are you attempting to use Bouncy Castle as your provider? > I used the command line tool "ssldump" to check what happens and > it seems the problem is in the cipher suite used by iPad: none of > the ciphers is accepted by the server. > > This is what ssldump command show: > > New TCP connection #1: > host35-105-static.24-87-b.business.telecomitalia.it(59049) <-> > 192.168.1.55(8443) 1 1 0.0979 (0.0979) C>S Handshake > ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA > TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 > TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA > TLS_DHE_DSS_WITH_NULL_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA > TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA > TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_MD5 compression methods > NULL > > iPad does try a few times, changing the version number, but it > fails every time and eventually stop. > > When connecting using Chrome on the very same iPad, the connection > works. Wow, I had no idea that Google Chrome was available for iOS. Cool! > The relevant dump is: > > New TCP connection #1: > host35-105-static.24-87-b.business.telecomitalia.it(59049) <-> > 192.168.1.55(8443) 1 1 0.0979 (0.0979) C>S Handshake > ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA > TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 > TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA > TLS_DHE_DSS_WITH_NULL_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA > TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA > TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_MD5 compression methods > NULL > > Ths cipher accepted by the server is: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA > > The connector I use is: > > maxThreads="150" scheme="https" secure="true" clientAuth="false" > sslProtocol="TLS" proxyName="www.my-visible-name.tld" > proxyPort="8443" address="192.168.1.55" /> It's traditional to specify a server key and certificate when configuring SSL. Where are yours configured? > So, my question: how to configure tomcat for accepting a broader > range of ciphers, or at least to accept even one of those used by > this browser? The default cipher suite depends upon your JVM, and is usually fairly inclusive. Here's a little program I wrote to find out what your JVM will support and what its default cipher suite will be: http://markmail.org/message/zn4namfhypyxum23 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEdEv8ACgkQ9CaO5/Lv0PCfAgCeIBzGP27N+gbTDAiLRcHOCO5K T7UAoJSZnWMPmSUpZZIfcE0L9ROaE7UX =OIY1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org