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
