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 >
