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 giuse...@eppesuigoccas.homedns.org 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 giuse...@eppesuigoccas.homedns.org 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
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
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
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
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. [...] Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true 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_128_SHA
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: [...] Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true 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
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
-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
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/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) CS 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) CS 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: Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true 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
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 ch...@christopherschultz.net 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
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) CS 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) CS 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: Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS proxyName=www.my-visible-name.tld proxyPort=8443 address=192.168.1.55 / 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
