[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-security-dev
Subject: Re: Not possible to disable new TLS extensions for TLS 1.2 connections
From: Amir Khassaia <amir.khassaia () gmail ! com>
Date: 2019-02-13 22:35:48
Message-ID: CAJ3+AwcDvJgzjybKd-fOs1fh1aKyCSAXE5fC5hu8LxEQiFjTyg () mail ! gmail ! com
[Download RAW message or body]
While this is somewhat similar its still a little different to what I was
asking because you can control named groups right now with the system
property, eg. jdk.tls.namedGroups (yes its global not ideal) and also at
the socket level but at least you dont have to drop TLS level.
For the other extensions I mentioned, you cannot control them at all you
have to drop TLS level, even a system property is better but of course
something per connection eg, SSLParameters is ideal.
On Thu, Feb 14, 2019 at 9:22 AM Thomas Lußnig <openjdk@suche.org> wrote:
> Hi,
>
> i check the old mails. In your case the problem was about the EC-Group
> extensions. If the server receive an unknown group he break the handshake
> with an alert. What was interesting is the fact it did not break after
> client hello but after Client-RSA-Key with alert illgegalParameter. I
> managed to establish the connection by disable all cipher suites using ec
> (only for this destination) not an good but an working solution.
> Maybe you can provide an ssl debug log or pcap so that is is possible to
> see if the same type of error happen.
>
> Gruß Thomas
>
> Sequence was:
>
> Client-Hello (SSLv3 - TLSv1.2)
> Server-Hello(SSLv3)
> Server-Certificates(SSLv3)
> Client-RSA-Key(TLSv1.2)
> Server-Alert(SSLv3 , FATAL , IllegalParameter)
>
>
> p.s. for the Problem with exception about unsupported group in jdk10
> (fixed in 11) i found an workaround by only offering RSA and no EC suites
> to the server that send 65535 as EC group that was causing the trouble.
> Am 13.02.2019 um 23:08:22 schrieb Amir Khassaia:
>
> Hi Thomas,
> Can you confirm its tied to new extensions to TLS 1.2 client hello and
> whether you diagnosed which one was the problem in Lotus Notes case ?
>
> On Thu, Feb 14, 2019 at 9:05 AM Thomas Lußnig <openjdk@suche.org> wrote:
>
>> Hi,
>>
>> maybe two points.
>>
>> 1) Older lotus notes server have the problem.
>> 2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2
>> 3) Maybe it would be an good idea to build an set of client hello's with
>> different options.
>> Or even an generator. Than you send if and check the result since
>> the servers with problem
>> only reply with an ssl alert. So you can check it without an ssl
>> engine or jdk build
>>
>>
>> Gruß Thomas
>>
>> Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan:
>> > Hi Amir,
>> >
>> > Could you build OpenJDK by yourself? If it is doable, I could send
>> > your a patch to disable the extension so that you can confirm if and
>> > which extension is the underlying problem.
>> >
>> > Thanks,
>> > Xuelei
>> >
>> >
>> > On 2/13/2019 1:16 PM, Amir Khassaia wrote:
>> >> Hi Xuelei,
>> >> There were 2 distinct cases of change of behaviour.
>> >>
>> >> * The "CN=invalid2.invalid, OU="No SNI provided" reliably works
>> >> without SNI in Java 8 but is indeed fixed by having an SNI included
>> >> which perhaps was needed all along. This one is reported by
>> XMPP/TLS
>> >> connection from talk.google.com:5222 <http://talk.google.com:5222>
>> >> * The aborted handshake case (client_hello traces that I've provided)
>> >> this happened with a hardware device which was replicable with an
>> >> SSL socket handshake program that I referenced in the gist.
>> >> Unfortunately replication requires a specific device model so it
>> >> wont be possible to see it for yourself. The workaround there was
>> to
>> >> either downgrade JRE to < 11 or to switch JRE globally to use TLS
>> >> 1.0 or TLS 1.1 via the system property. This is where your proposed
>> >> enhancement will be of great help as it will allow a per connection
>> >> type decision.
>> >>
>> >>
>> >> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei.fan@oracle.com
>> >> <mailto:xuelei.fan@oracle.com>> wrote:
>> >>
>> >> Hi Amir,
>> >>
>> >> It should be rare now the a TLS vendor cannot ignore unknown
>> >> extensions.
>> >>
>> >> > "issuer": "CN=invalid2.invalid, OU="No SNI provided;
>> >> > please fix your client."",
>> >> The error message encapsulated in the certificate does not sound
>> >> right
>> >> to me. Is it caused by the absence of SNI extension?
>> >>
>> >> Did you have a test case that I can reproduce the problem?
>> >>
>> >> Thanks & Regards,
>> >> Xuelei
>> >>
>> >>
>> >> On 1/7/2019 9:27 PM, Amir Khassaia wrote:
>> >> > Xuelei,
>> >> > The certificate in the connection is a red herring and not
>> >> important.
>> >> > It's actually a very unusual behaviour by talk.google.com
>> >> <http://talk.google.com>
>> >> > <http://talk.google.com> endpoint to encapsulate an error
>> message
>> >> inside
>> >> > a certificate.
>> >> >
>> >> > As per the output I included:
>> >> >
>> >> > /"certificate" : { />/ "version" : "v3", />/
>> >> "serial number" : "00 90 76 89 18 E9 33 93 A0", />/
>> >> "signature algorithm": "SHA256withRSA", />/ "issuer"
>> >> : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your
>> >> client."", />/ "not before" : "2015-01-01 11:00:00.000
>> >> AEDT", />/ "not after" : "2030-01-01 11:00:00.000
>> AEDT",
>> >> />/ "subject" : "CN=invalid2.invalid, OU="No SNI
>> >> provided; />/please fix your client."",/
>> >> >
>> >> > /
>> >> > /
>> >> >
>> >> > This certificate simply masks the TLS interoperability issue
>> >> as an
>> >> > untrusted certificate issue.
>> >> >
>> >> > The fact is, some of the extensions sent by JSSE are changes to
>> >> TLS 1.2
>> >> > to support TLS 1.3, this however affects some clients
>> >> adversely in
>> >> > practice and usually JDK provides properties to turn new
>> >> enhancements
>> >> > off and work around such behaviour, for the extensions I
>> >> mentioned this
>> >> > is not provided and hence they are always sent for client
>> sockets
>> >> unless
>> >> > TLSv1.2 is not in use.
>> >> >
>> >> > The impact to us is that upgrading to JDK11 means for some
>> >> endpoints or
>> >> > devices that are not 100% compliant to the spec the security is
>> >> reduced
>> >> > as we have to now work around to drop connections to these to
>> >> TLSv1.1 or
>> >> > TLS1.0 or not to move to Java 11 at all.
>> >> >
>> >> > My request is simply to have all of the new extensions
>> >> configurable on
>> >> > individual basis so that they can be turned off if needed for
>> >> > compatibility just like most other security enhancements that
>> >> were
>> >> > delivered in the past.
>> >> >
>> >> > It appears some of the issues can come from
>> >> >
>> >> > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these
>> can
>> >> > disabled at least
>> >> >
>> >> > -signature_algorithms_cert and supported_versions extensions
>> >> which seem
>> >> > to be hardcoded for TLS 1.2 (I was not able to conclusively
>> >> identify
>> >> > which of these caused my troubles)
>> >> >
>> >> > https://tools.ietf.org/html/rfc8446#section-1.3 does say that
>> TLS
>> >> 1.2
>> >> > clients are affected but in an optional manner.Just today I've
>> >> > encountered another Java 11 interop issue with TLS but this time
>> >> with a
>> >> > physical device which can have a long shelf life yet running a
>> >> simple
>> >> > client socket handshake abruptly terminates the connection upon
>> >> client
>> >> > hello (no server_hello at all), and downgrading the JRE below 11
>> >> works
>> >> > fine. I'm including a trace for that as well:
>> >> >
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395
>> >> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry =
>> >> AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE
>> >> =137438953472
>> >> >
>> >> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
>> >> > AEDT|ServerNameExtension.java:255|Unable to indicate server name
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>> >> > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >> > server_name
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>> >> > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >> > status_request
>> >> >
>> >> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
>> >> > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is
>> >> not
>> >> > supported by the underlying providers
>> >> >
>> >> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
>> >> > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
>> >> > supported by the underlying providers
>> >> >
>> >> > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
>> >> > AEDT|AlpnExtension.java:161|No available application protocols
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
>> >> > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >> > application_layer_protocol_negotiation
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
>> >> > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >> > status_request_v2
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
>> >> > AEDT|ClientHello.java:651|Produced ClientHello handshake
>> >> message (
>> >> >
>> >> > "ClientHello": {
>> >> >
>> >> > "client version" : "TLSv1.2",
>> >> >
>> >> > "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24
>> >> 7F 34 3D
>> >> > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
>> >> >
>> >> > "session id" : "",
>> >> >
>> >> > "cipher suites" :
>> >> > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
>> >> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
>> >> > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
>> >> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
>> >> > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
>> >> >
>> >> > "compression methods" : "00",
>> >> >
>> >> > "extensions" : [
>> >> >
>> >> > "supported_groups (10)": {
>> >> >
>> >> > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
>> >> >
>> >> > },
>> >> >
>> >> > "ec_point_formats (11)": {
>> >> >
>> >> > "formats": [uncompressed]
>> >> >
>> >> > },
>> >> >
>> >> > "signature_algorithms (13)": {
>> >> >
>> >> > "signature schemes": [ecdsa_secp256r1_sha256,
>> >> ecdsa_secp384r1_sha384,
>> >> > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256,
>> rsa_pss_rsae_sha384,
>> >> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>> >> > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>> >> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
>> >> dsa_sha224,
>> >> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>> >> >
>> >> > },
>> >> >
>> >> > "signature_algorithms_cert (50)": {
>> >> >
>> >> > "signature schemes": [ecdsa_secp256r1_sha256,
>> >> ecdsa_secp384r1_sha384,
>> >> > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256,
>> rsa_pss_rsae_sha384,
>> >> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>> >> > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>> >> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
>> >> dsa_sha224,
>> >> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>> >> >
>> >> > },
>> >> >
>> >> > "extended_master_secret (23)": {
>> >> >
>> >> > <empty>
>> >> >
>> >> > },
>> >> >
>> >> > "supported_versions (43)": {
>> >> >
>> >> > "versions": [TLSv1.2, TLSv1.1]
>> >> >
>> >> > },
>> >> >
>> >> > "renegotiation_info (65,281)": {
>> >> >
>> >> > "renegotiated connection": [<no renegotiated connection>]
>> >> >
>> >> > }
>> >> >
>> >> > ]
>> >> >
>> >> > }
>> >> >
>> >> > )
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
>> >> > AEDT|Alert.java:232|Received alert message (
>> >> >
>> >> > "Alert": {
>> >> >
>> >> > "level" : "fatal",
>> >> >
>> >> > "description": "handshake_failure"
>> >> >
>> >> > }
>> >> >
>> >> > )
>> >> >
>> >> > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
>> >> > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
>> >> Received fatal
>> >> > alert: handshake_failure (
>> >> >
>> >> > "throwable" : {
>> >> >
>> >> > javax.net.ssl.SSLHandshakeException: Received fatal alert:
>> >> > handshake_failure
>> >> >
>> >> > at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>> >> >
>> >> > at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>> >> >
>> >> > at
>> >> >
>> >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>> >> >
>> >> > at
>> >> >
>> >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>> >> >
>> >> > at SslSocketClient.main(SslSocketClient.kt:47)}
>> >> >
>> >> >
>> >> > )
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>> >> > AEDT|SSLSocketImpl.java:1361|close the underlying socket
>> >> >
>> >> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>> >> > AEDT|SSLSocketImpl.java:1380|close the SSL connection
>> >> (initiative)
>> >> >
>> >> > Exception in thread "main" javax.net.ssl.SSLHandshakeException:
>> >> Received
>> >> > fatal alert: handshake_failure
>> >> >
>> >> > at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>> >> >
>> >> > at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>> >> >
>> >> > at
>> >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>> >> >
>> >> > at
>> >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>> >> >
>> >> > at
>> >> >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>> >> >
>> >> > at SslSocketClient.main(SslSocketClient.kt:47)
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>>
>
[Attachment #3 (text/html)]
<div dir="ltr">While this is somewhat similar its still a little different to what I \
was asking because you can control named groups right now with the system property, \
eg. jdk.tls.namedGroups (yes its global not ideal) and also at the socket level but \
at least you dont have to drop TLS level.<div>For the other extensions I mentioned, \
you cannot control them at all you have to drop TLS level, even a system property is \
better but of course something per connection eg, SSLParameters is \
ideal.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 9:22 AM Thomas Lußnig <<a \
href="mailto:openjdk@suche.org">openjdk@suche.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi,</p>
<p>i check the old mails. In your case the problem was about the
EC-Group extensions. If the server receive an unknown group he
break the handshake with an alert. What was interesting is the
fact it did not break after client hello but after Client-RSA-Key
with alert illgegalParameter. I managed to establish the
connection by disable all cipher suites using ec (only for this
destination) not an good but an working solution.<br>
Maybe you can provide an ssl debug log or pcap so that is is
possible to see if the same type of error happen.<br>
</p>
<p>Gruß Thomas<br>
</p>
<p>Sequence was:</p>
<p>Client-Hello (SSLv3 - TLSv1.2)<br>
Server-Hello(SSLv3)<br>
Server-Certificates(SSLv3)<br>
Client-RSA-Key(TLSv1.2)<br>
Server-Alert(SSLv3 , FATAL , IllegalParameter)</p>
<p><br>
</p>
<p>p.s. for the Problem with exception about unsupported group in
jdk10 (fixed in 11) i found an workaround by only offering RSA and
no EC suites<br>
to the server that send 65535 as EC group that was causing the
trouble.</p>
<div class="gmail-m_-4351653415133600136moz-cite-prefix">Am 13.02.2019 um \
23:08:22 schrieb Amir Khassaia:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Thomas,
<div>Can you confirm its tied to new extensions to TLS 1.2
client hello and whether you diagnosed which one was the
problem in Lotus Notes case ?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 9:05
AM Thomas Lußnig <<a href="mailto:openjdk@suche.org" \
target="_blank">openjdk@suche.org</a>> wrote:<br> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br>
maybe two points.<br>
<br>
1) Older lotus notes server have the problem.<br>
2) The problem can be solved if you disable TLSv1.3 or even
TLSv1.2<br>
3) Maybe it would be an good idea to build an set of client
hello's with <br>
different options.<br>
Or even an generator. Than you send if and check the
result since <br>
the servers with problem<br>
only reply with an ssl alert. So you can check it
without an ssl <br>
engine or jdk build<br>
<br>
<br>
Gruß Thomas<br>
<br>
Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan:<br>
> Hi Amir,<br>
><br>
> Could you build OpenJDK by yourself? If it is doable, I
could send <br>
> your a patch to disable the extension so that you can
confirm if and <br>
> which extension is the underlying problem.<br>
><br>
> Thanks,<br>
> Xuelei<br>
><br>
><br>
> On 2/13/2019 1:16 PM, Amir Khassaia wrote:<br>
>> Hi Xuelei,<br>
>> There were 2 distinct cases of change of behaviour.<br>
>><br>
>> * The "CN=invalid2.invalid, OU="No SNI provided"
reliably works<br>
>> without SNI in Java 8 but is indeed fixed by
having an SNI included<br>
>> which perhaps was needed all along. This one is
reported by XMPP/TLS<br>
>> connection from <a href="http://talk.google.com:5222" \
rel="noreferrer" target="_blank">talk.google.com:5222</a>
<<a href="http://talk.google.com:5222" rel="noreferrer" \
target="_blank">http://talk.google.com:5222</a>><br> >> * The aborted \
handshake case (client_hello traces that I've provided)<br>
>> this happened with a hardware device which was
replicable with an<br>
>> SSL socket handshake program that I referenced in
the gist.<br>
>> Unfortunately replication requires a specific
device model so it<br>
>> wont be possible to see it for yourself. The
workaround there was to<br>
>> either downgrade JRE to < 11 or to switch JRE
globally to use TLS<br>
>> 1.0 or TLS 1.1 via the system property. This is
where your proposed<br>
>> enhancement will be of great help as it will
allow a per connection<br>
>> type decision.<br>
>><br>
>><br>
>> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <<a \
href="mailto:xuelei.fan@oracle.com" \
target="_blank">xuelei.fan@oracle.com</a> <br>
>> <mailto:<a href="mailto:xuelei.fan@oracle.com" \
target="_blank">xuelei.fan@oracle.com</a>>> wrote:<br>
>><br>
>> Hi Amir,<br>
>><br>
>> It should be rare now the a TLS vendor cannot
ignore unknown <br>
>> extensions.<br>
>><br>
>> > "issuer": "CN=invalid2.invalid, \
OU="No SNI provided;<br>
>> > please fix your client."",<br>
>> The error message encapsulated in the certificate
does not sound <br>
>> right<br>
>> to me. Is it caused by the absence of SNI
extension?<br>
>><br>
>> Did you have a test case that I can reproduce the
problem?<br>
>><br>
>> Thanks & Regards,<br>
>> Xuelei<br>
>><br>
>><br>
>> On 1/7/2019 9:27 PM, Amir Khassaia wrote:<br>
>> > Xuelei,<br>
>> > The certificate in the connection is a red
herring and not<br>
>> important.<br>
>> > It's actually a very unusual behaviour by <a \
href="http://talk.google.com" rel="noreferrer" \
target="_blank">talk.google.com</a><br>
>> <<a href="http://talk.google.com" rel="noreferrer" \
target="_blank">http://talk.google.com</a>><br>
>> > <<a href="http://talk.google.com" \
rel="noreferrer" target="_blank">http://talk.google.com</a>> endpoint to \
encapsulate an error message<br> >> inside<br>
>> > a certificate.<br>
>> ><br>
>> > As per the output I included:<br>
>> ><br>
>> > /"certificate" : { />/ \
"version" : "v3", />/ <br>
>> "serial number" : "00 90 76 89 18 E9 \
33 93 A0", />/ <br>
>> "signature algorithm": "SHA256withRSA", />/ \
"issuer" <br>
>> : "CN=invalid2.invalid, OU="No SNI provided;
/>/please fix your<br>
>> client."", />/ "not before" \
: "2015-01-01 11:00:00.000<br>
>> AEDT", />/ "not after" \
: "2030-01-01 11:00:00.000 AEDT",<br>
>> />/ "subject" :
"CN=invalid2.invalid, OU="No SNI<br>
>> provided; />/please fix your client."",/<br>
>> ><br>
>> > /<br>
>> > /<br>
>> ><br>
>> > This certificate simply masks the TLS
interoperability issue <br>
>> as an<br>
>> > untrusted certificate issue.<br>
>> ><br>
>> > The fact is, some of the extensions sent by
JSSE are changes to<br>
>> TLS 1.2<br>
>> > to support TLS 1.3, this however affects
some clients <br>
>> adversely in<br>
>> > practice and usually JDK provides
properties to turn new<br>
>> enhancements<br>
>> > off and work around such behaviour, for the
extensions I<br>
>> mentioned this<br>
>> > is not provided and hence they are always
sent for client sockets<br>
>> unless<br>
>> > TLSv1.2 is not in use.<br>
>> ><br>
>> > The impact to us is that upgrading to JDK11
means for some<br>
>> endpoints or<br>
>> > devices that are not 100% compliant to the
spec the security is<br>
>> reduced<br>
>> > as we have to now work around to drop
connections to these to<br>
>> TLSv1.1 or<br>
>> > TLS1.0 or not to move to Java 11 at all.<br>
>> ><br>
>> > My request is simply to have all of the new
extensions<br>
>> configurable on<br>
>> > individual basis so that they can be turned
off if needed for<br>
>> > compatibility just like most other security
enhancements that <br>
>> were<br>
>> > delivered in the past.<br>
>> ><br>
>> > It appears some of the issues can come from<br>
>> ><br>
>> > - inclusion of RSASSA-PSS alg in TLS 1.2
handshakes but these can<br>
>> > disabled at least<br>
>> ><br>
>> > -signature_algorithms_cert and
supported_versions extensions<br>
>> which seem<br>
>> > to be hardcoded for TLS 1.2 (I was not able
to conclusively <br>
>> identify<br>
>> > which of these caused my troubles)<br>
>> ><br>
>> > <a \
href="https://tools.ietf.org/html/rfc8446#section-1.3" rel="noreferrer" \
target="_blank">https://tools.ietf.org/html/rfc8446#section-1.3</a> does say that \
TLS<br> >> 1.2<br>
>> > clients are affected but in an optional
manner.Just today I've<br>
>> > encountered another Java 11 interop issue
with TLS but this time<br>
>> with a<br>
>> > physical device which can have a long shelf
life yet running a<br>
>> simple<br>
>> > client socket handshake abruptly terminates
the connection upon<br>
>> client<br>
>> > hello (no server_hello at all), and
downgrading the JRE below 11<br>
>> works<br>
>> > fine. I'm including a trace for that as
well:<br>
>> ><br>
>> ><br>
>> >
javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395 <br>
>> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry =<br>
>> AES/GCM/NoPadding KeyUpdate2^37.
AES/GCM/NOPADDING:KEYUPDATE<br>
>> =137438953472<br>
>> ><br>
>> > javax.net.ssl|WARNING|01|main|2019-01-08
13:40:14.433<br>
>> > AEDT|ServerNameExtension.java:255|Unable to
indicate server name<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.433<br>
>> > AEDT|SSLExtensions.java:235|Ignore, context
unavailable <br>
>> extension:<br>
>> > server_name<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.433<br>
>> > AEDT|SSLExtensions.java:235|Ignore, context
unavailable <br>
>> extension:<br>
>> > status_request<br>
>> ><br>
>> > javax.net.ssl|WARNING|01|main|2019-01-08
13:40:14.443<br>
>> > AEDT|SignatureScheme.java:282|Signature
algorithm, ed25519, is <br>
>> not<br>
>> > supported by the underlying providers<br>
>> ><br>
>> > javax.net.ssl|WARNING|01|main|2019-01-08
13:40:14.444<br>
>> > AEDT|SignatureScheme.java:282|Signature
algorithm, ed448, is not<br>
>> > supported by the underlying providers<br>
>> ><br>
>> > javax.net.ssl|INFO|01|main|2019-01-08
13:40:14.449<br>
>> > AEDT|AlpnExtension.java:161|No available
application protocols<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.449<br>
>> > AEDT|SSLExtensions.java:235|Ignore, context
unavailable <br>
>> extension:<br>
>> > application_layer_protocol_negotiation<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.450<br>
>> > AEDT|SSLExtensions.java:235|Ignore, context
unavailable <br>
>> extension:<br>
>> > status_request_v2<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.453<br>
>> > AEDT|ClientHello.java:651|Produced
ClientHello handshake <br>
>> message (<br>
>> ><br>
>> > "ClientHello": {<br>
>> ><br>
>> > "client version" : \
"TLSv1.2",<br> >> ><br>
>> > "random" : "1A BA \
E8 FC 59 00 AB DF 9A 1A 07 94 24<br>
>> 7F 34 3D<br>
>> > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42
C6 68",<br>
>> ><br>
>> > "session id" : \
"",<br> >> ><br>
>> > "cipher suites" :<br>
>> >
"[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),<br>
>> >
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),<br>
>> > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),<br>
>> >
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),<br>
>> > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",<br>
>> ><br>
>> > "compression methods" : \
"00",<br> >> ><br>
>> > "extensions" : [<br>
>> ><br>
>> > "supported_groups (10)": {<br>
>> ><br>
>> > "versions": [secp256r1, secp384r1,
secp521r1, secp160k1]<br>
>> ><br>
>> > },<br>
>> ><br>
>> > "ec_point_formats (11)": {<br>
>> ><br>
>> > "formats": [uncompressed]<br>
>> ><br>
>> > },<br>
>> ><br>
>> > "signature_algorithms (13)": {<br>
>> ><br>
>> > "signature schemes":
[ecdsa_secp256r1_sha256,<br>
>> ecdsa_secp384r1_sha384,<br>
>> > ecdsa_secp512r1_sha512,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,<br>
>> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384,<br>
>> > rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384,<br>
>> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, <br>
>> dsa_sha224,<br>
>> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1,
rsa_md5]<br>
>> ><br>
>> > },<br>
>> ><br>
>> > "signature_algorithms_cert (50)": {<br>
>> ><br>
>> > "signature schemes":
[ecdsa_secp256r1_sha256,<br>
>> ecdsa_secp384r1_sha384,<br>
>> > ecdsa_secp512r1_sha512,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,<br>
>> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384,<br>
>> > rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384,<br>
>> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, <br>
>> dsa_sha224,<br>
>> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1,
rsa_md5]<br>
>> ><br>
>> > },<br>
>> ><br>
>> > "extended_master_secret (23)": {<br>
>> ><br>
>> > <empty><br>
>> ><br>
>> > },<br>
>> ><br>
>> > "supported_versions (43)": {<br>
>> ><br>
>> > "versions": [TLSv1.2, TLSv1.1]<br>
>> ><br>
>> > },<br>
>> ><br>
>> > "renegotiation_info (65,281)": {<br>
>> ><br>
>> > "renegotiated connection": [<no
renegotiated connection>]<br>
>> ><br>
>> > }<br>
>> ><br>
>> > ]<br>
>> ><br>
>> > }<br>
>> ><br>
>> > )<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.455<br>
>> > AEDT|Alert.java:232|Received alert message
(<br>
>> ><br>
>> > "Alert": {<br>
>> ><br>
>> > "level" : "fatal",<br>
>> ><br>
>> > "description": \
"handshake_failure"<br> >> ><br>
>> > }<br>
>> ><br>
>> > )<br>
>> ><br>
>> > javax.net.ssl|ERROR|01|main|2019-01-08
13:40:14.456<br>
>> > AEDT|TransportContext.java:313|Fatal
(HANDSHAKE_FAILURE):<br>
>> Received fatal<br>
>> > alert: handshake_failure (<br>
>> ><br>
>> > "throwable" : {<br>
>> ><br>
>> > javax.net.ssl.SSLHandshakeException:
Received fatal alert:<br>
>> > handshake_failure<br>
>> ><br>
>> > at<br>
>>
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)<br>
>> ><br>
>> > at<br>
>>
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)<br>
>> ><br>
>> > at<br>
>> > <br>
>>
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)<br>
>> ><br>
>> > at
SslSocketClient.main(SslSocketClient.kt:47)}<br>
>> ><br>
>> ><br>
>> > )<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.457<br>
>> > AEDT|SSLSocketImpl.java:1361|close the
underlying socket<br>
>> ><br>
>> > javax.net.ssl|DEBUG|01|main|2019-01-08
13:40:14.457<br>
>> > AEDT|SSLSocketImpl.java:1380|close the SSL
connection <br>
>> (initiative)<br>
>> ><br>
>> > Exception in thread "main"
javax.net.ssl.SSLHandshakeException:<br>
>> Received<br>
>> > fatal alert: handshake_failure<br>
>> ><br>
>> > at<br>
>>
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)<br>
>> ><br>
>> > at<br>
>>
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)<br>
>> ><br>
>> > at<br>
>>
java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)<br>
>> ><br>
>> > at<br>
>>
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)<br>
>> ><br>
>> > at<br>
>> ><br>
>>
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)<br>
>> ><br>
>> > at
SslSocketClient.main(SslSocketClient.kt:47)<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic