Ignore SSL server_name extension alerts (Bug 7127374)

Mon Apr 15 03:40:30 UTC 2013

On 1/21/2013 7:25 AM, Bernd Eckenfels wrote:
> Hello,
> 
> quite some time back I reported a bug, that the SSLSocket of Java will
> terminate connections to servers which respond with a unrecognized_name
> alert.
> 
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374
> 
> This was introduced since the SSLSocket started to send the SNI
> extension record in the client hello. My bug was closed without giving
> me the chance to comment on the analysis, so I will do that here now:
> 
It is the right place to comment more here. Thanks for coming here to
make the issue clearer.

> The sample SSL Server on timestamp.geotrust.com:443 (still) responds
> with a unrecognized_name alert when you sent a SNI extension. (It is
> most likely wronly configured, since there are a lot of different CA
> francises behind that infrastructure).
> 
> However the alert which is received by the SSL client is only a warning
> level, and it could be ignored by the SSL library. openssl or web
> browsers do continue if they get such a warning. I would argue the same
> should happen for Java.
> 
It could happen in Java in application level.  However, in TLS level, it
may be not continuable because the server may not deliver the handshake
messages to continue the handshaking after a warning message. In
application level, for example web browsers, the client can request
another handshaking without SNI extension, to "continue" with a new
handshaking.  JSSE does not support this feature at present.
Application can ask for a new handshaking w/o new extensions instead.

> In fact I wonder if we need a API for SSLSockets which allow to set more
> options like
> 
> - what extensions to send
It is expected that the server side can ignore unknown extensions.  In
JDK 8, application can choose whether to use SNI extension or not.

> - what warnings to accept
The warning message is not very useful. See section 7.2.2, RFC5246.

> - what type of renegotiation (and how often) is allowed
> 
sorry, I did get it. What are the types of renegotiation?  If it is
refer to normal TLS handshaking, application level can do it, I think.

Regards,
Xuelei

> It should also have a getWarnings() method (similiar to JDBC).
> 
> BTW: the class SimpleBIOSSLClient on
> 
> https://github.com/ecki/JavaCryptoTest/tree/master/src/main/java/net/eckenfels/test/ssl
> 
> 
> will try to do a SSL handshake with hardcoded code and print the output.
> If you connect that to the geotrust server you can clearly see, that the
> handshake received is a warning and the endpoint continues with further
> handshake steps. (see output below). The client is not completed yet, so
> the Finish message is not valid yet, so this is why you see a second
> (fatal) alert.
> 
> I think ignoring the unrecognized_name alert is no security problem, as
> you will verify the endpoint via the received certificate anway.
> 
>>>> Record type=22 version=3.1 len=118
>   Handshake client_hello len=114
>     bytes=03 01 ff ff ff ff 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33
> 44 11 22 33 44 11 22 33 44 11 22 33 44 00 00 2a 00 0a 00 07 00 05 00 04
> 00 39 00 13 00 66 00 65 00 64 00 63 00 62 00 61 00 60 00 15 00 12 00 09
> 00 14 00 11 00 08 00 06 00 03 01 00 00 1f 00 00 00 1b 00 19 00 00 16 74
> 69 6d 65 73 74 61 6d 70 2e 67 65 6f 74 72 75 73 74 2e 63 6f 6d
> <<< Record type=22 version=3.1 len=80
>   Handshake server_hello len=76
>     Version=3.1
>     serverrandom=50 fc 7b 24 28 ac 20 67 2b 6a b9 e7 63 b8 75 7b 41 d3
> 1f 5c ad 73 7f ff 17 38 91 4d 94 02 48 ff
>     session  =32/6a d8 1d c4 7d 7f d3 17 82 55 bd 32 9b cf 17 d5 35 55
> ff 0b c0 ff 5b e2 60 cc 16 db a1 e7 91 77
>     suite=10 compression=0
>     bytes=00 04 00 00 00 00
> <<< Record type=22 version=3.1 len=876
>   Handshake certificate len=872
>     listlen=869
>       DN=CN=timestamp.geotrust.com, OU=Production Security Services,
> O=GeoTrust Inc., L=Mountain View, ST=California, C=US,
> SERIALNUMBER=zeSjNRSVdrWJbAzTb281UTdfbGNtENPJ RSA/500
> <<< Record type=22 version=3.1 len=4
>   Handshake server_hello_done len=0
>>>> Record type=22 version=3.1 len=134
>   Handshake client_key_exchange len=130
>     bytes=00 80 78 bd f4 70 af 2e f2 d4 7c 11 74 5e 9c 51 12 63 d2 96 99
> 07 3a ec 19 c5 b6 76 4a 2c da 21 d7 31 6c c6 6e 8a 70 73 80 1f dd 7a e6
> 5f 58 9b ae 29 92 8b 3c 12 fd f7 b6 8b 13 d6 fa 04 46 84 6e 05 3e 12 a4
> 87 90 3f 3f 8c 5d 1b 00 65 a4 22 fa 4e 2d b4 6a ec 21 aa 8f f0 0f df 63
> cb 8e 6c 1c 05 15 35 fa 53 1d ad 3f fb 3f 3a c0 ce fb 5f 89 a7 c6 6c 1d
> 2b 98 20 92 37 10 fc 0f 08 11 1d dc 22
>>>> Record type=20 version=3.1 len=1
>   Change Cipher Spec
>     bytes=01
>>>> Record type=22 version=3.1 len=36
>   Handshake Encrypted
>     bytes=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> <<< Record type=21 version=3.1 len=2
>   Alert len=7
>     fatal(2) decryption_failed
> 
> BTW: openssl s_server has a option if the alert should be warning or
> fatal, so it can be expected the servers decide for themself if they
> want to continue or not.
> 
> Greetings
> Bernd
> 
> PS: there are more affected than only the above time stamping authority
> (and jarsigner):
> -
> http://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name-error-since-upgrade-to-java-1-7-0
> 
> - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177232
>