You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Giuseppe Sacco <gi...@eppesuigoccas.homedns.org> on 2013/02/13 22:47:40 UTC
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:
<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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL
connector with JSSE ciphers
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Giuseppe Sacco <gi...@eppesuigoccas.homedns.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Martin Gainty <mg...@hotmail.com>.
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: chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
> <gi...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL
connector with JSSE ciphers
Posted by Tim Whittington <ti...@apache.org>.
On Tue, Feb 19, 2013 at 10:59 AM, Giuseppe Sacco
<gi...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Giuseppe Sacco <gi...@eppesuigoccas.homedns.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Giuseppe Sacco <gi...@eppesuigoccas.homedns.org>.
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(60000) called
[Raw read]: length = 5
0000: 16 03 00 00 4B ....K
[Raw read]: length = 75
0000: 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
0000: 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
0000: 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Giuseppe Sacco <gi...@eppesuigoccas.homedns.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Giuseppe Sacco <gi...@eppesuigoccas.homedns.org>.
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
< * 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
Thanks,
Giuseppe
Re: Tomcat does not accept connections from Safari on iPad vs an
SSL connector with JSSE ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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:
>
> <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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Posted by Esmond Pitt <es...@bigpond.com>.
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:giuseppe@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:
<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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org