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