Ignore SSL server_name extension alerts (Bug 7127374)

Mon Apr 15 14:42:21 UTC 2013

Hello,

Will answer in detail, but just make sure People are Not confused: the TSA seems to be fixed meanwhile.

Gruss
Bernd
-- 
bernd.eckenfels.net

Am 15.04.2013 um 05:40 schrieb Xuelei Fan <xuelei.fan at oracle.com>:

> 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
>> 
> 