Ignore SSL server_name extension alerts (Bug 7127374)

Sun Jan 20 23:25:08 UTC 2013

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:

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.

In fact I wonder if we need a API for SSLSockets which allow to set more  
options like

- what extensions to send
- what warnings to accept
- what type of renegotiation (and how often) is allowed

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

-- 
http://bernd.eckenfels.net