TlsClientProtocol and TLSv1.0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

TlsClientProtocol and TLSv1.0

Bill Somerville

Hi.  I'm running BC 1.55 on Java 6.  Recently, I had to start using TlsClientProtocol due to a site that went TLS 1.2 only, and the built-in Java 6 SSL stuff stopped working.  TlsClientProtocol is working great for sites with TLS 1.1 and TLS 1.2, however I have some internal sites that also run on Java 6, so only support TLS 1.0.  Contacting these sites results in:

 

java.io.IOException: Internal TLS error, this could be an attack

      at org.bouncycastle.crypto.tls.TlsProtocol.failWithError(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsProtocol.completeHandshake(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown Source)

      …my SSLSocket.startHandshake()…

 

As it happens, "openssl s_client -no_tls1_1 -no_tls1_2" has no issue connecting to the same site:

 

issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2

---

No client certificate CA names sent

Server Temp Key: DH, 2048 bits

---

SSL handshake has read 5900 bytes and written 600 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA

Server public key is 2048 bit

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

SSL-Session:

    Protocol  : TLSv1

    Cipher    : DHE-RSA-AES128-SHA

    Session-ID: A7E1D409CDFAD52CB1EFF54F7BF859AB013C9DDBFB2B24CC7A60CB1D0DA938B8

    Session-ID-ctx:

    Master-Key: 94469EE0BB372DF9390E195D0DCC32785F30E76B082E0EDE64700F0284B45722A14E50E65FB32214A64380DB4D8C89DD

    Key-Arg   : None

    PSK identity: None

    PSK identity hint: None

    SRP username: None

    TLS session ticket:

    0000 - 33 74 98 8e cf 8f c0 87-f1 1a 80 c8 cf 1a 71 6c   3t............ql

    0010 - 39 ce e3 93 bc d8 06 bb-86 5b bd b4 17 26 e8 d3   9........[...&..

    0020 - 91 ea c4 b7 64 0f 55 ee-4f dd 10 e4 ef 9c 2d 9d   ....d.U.O.....-.

    0030 - 21 73 3a 11 b8 d2 b3 61-2f a7 50 36 9e 03 a2 e9   !s:....a/.P6....

    0040 - b9 73 1b 25 49 a7 df 5a-41 b1 91 d8 dc 11 2c a9   .s.%I..ZA.....,.

    0050 - 04 6b 54 89 5a 5a 54 0b-4a d7 62 38 52 8a ed 55   .kT.ZZT.J.b8R..U

    0060 - d0 97 58 11 5b 0b a8 de-d1 2a c5 ef 69 be 01 54   ..X.[....*..i..T

    0070 - c9 4d b1 13 55 1f 02 c0-a0 a9 44 97 c1 5e c3 84   .M..U.....D..^..

    0080 - 99 77 03 86 0c 59 4b 1e-1a 95 00 2e 2a a5 9f 8b   .w...YK.....*...

    0090 - 05 e5 56 11 19 31 17 fe-16 1c 9d 41 51 15 60 01   ..V..1.....AQ.`.

 

    Start Time: 1477677661

    Timeout   : 300 (sec)

 

                Is TLS 1.0 disabled by default (and if so, how do I enable it), or is this some other problem?

 

                Looking at the code, the stack trace doesn't make a lot of sense, but it would be kind of nice if failWithError() would include the cause when throwing this exception.  That is:

 

throw new IOException(TLS_ERROR_MESSAGE);

 

…would be more useful if it was (assuming cause is ever non-null):

 

throw new IOException(TLS_ERROR_MESSAGE, cause);

 

                Thanks…

 

-- Bill

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TlsClientProtocol and TLSv1.0

Peter Dettman-3
Hi Bill,

On 28/10/2016 8:28 PM, Bill Somerville wrote:
> Hi.  I'm running BC 1.55 on Java 6.  Recently, I had to start using
> TlsClientProtocol due to a site that went TLS 1.2 only, and the
> built-in Java 6 SSL stuff stopped working.  TlsClientProtocol is
> working great for sites with TLS 1.1 and TLS 1.2, however I have some
> internal sites that also run on Java 6, so only support TLS 1.0.
> Contacting these sites results in:
>
> java.io.IOException: Internal TLS error, this could be an attack

> Is TLS 1.0 disabled by default (and if so, how do I enable it), or is
> this some other problem?

The minimum version the client will accept is returned by
TlsClient.getMinimumVersion, which by default (AbstractTlsClient) is TLS
1.0. See also getClientVersion for the offered (maximum) version
(default TLS 1.2).


> Looking at the code, the stack trace doesn't make a lot of sense, but
> it would be kind of nice if failWithError() would include the cause
> when throwing this exception.  That is:
>
> throw new IOException(TLS_ERROR_MESSAGE);
>
> …would be more useful if it was (assuming cause is ever non-null):
>
> throw new IOException(TLS_ERROR_MESSAGE, cause);

The (somewhat weak) reason it's not passed is that the 'cause' parameter
is only available since 1.4, and we still support even earlier versions.

To get better information about the underlying error, I suggest
implementing the notifyAlertRaised method in your TlsClient
implementation, presumably a subclass of DefaultTlsClient. The 'cause'
is included as an argument to that call.

e.g. see
https://github.com/bcgit/bc-java/blob/master/core/src/test/java/org/bouncycastle/crypto/tls/test/MockTlsClient.java

If it's actually the server raising the error, implementing
notifyAlertReceived will let you see what type of alert it sent. If it
IS the server failing the handshake, the first thing to check is that
there is actually at least one ciphersuite in common b/w the
client/server configurations.

If you can post a followup with some of that information, it shouldn't
be too difficult to figure out what's wrong.

Regards,
Pete Dettman

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: TlsClientProtocol and TLSv1.0

Bill Somerville

Hi, Peter:

                Thanks for the response.  Here's what I get in notifyAlertRaised:

Minimum version: TLS 1.0 (I display this from DefaultTlsClient. getMinimumVersion())

 

notifyAlertRaised: alertLevel 2 alertDescription 40: Failed to read record

org.bouncycastle.crypto.tls.TlsFatalAlert: handshake_failure(40)

      at org.bouncycastle.crypto.tls.AbstractTlsPeer.notifySecureRenegotiation(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsClientProtocol.receiveServerHelloMessage(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsProtocol.processHandshake(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsProtocol.processRecord(Unknown Source)

      at org.bouncycastle.crypto.tls.RecordStream.readRecord(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsProtocol.completeHandshake(Unknown Source)

      at org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown Source)

 

In the case of the client, I default everything.  For the server, as mentioned in my original post, from s_client:

Cipher    : DHE-RSA-AES128-SHA

 

Using nmap, I enumerated the ciphers supported by the server in question:

 

Nmap scan report for 10.0.1.112

Host is up (0.00s latency).

PORT    STATE SERVICE

443/tcp open  https

| ssl-enum-ciphers:

|   SSLv3: No supported ciphers found

|   TLSv1.0:

|     ciphers:

|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong

|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong

|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong

|       TLS_RSA_WITH_AES_128_CBC_SHA - strong

|       TLS_RSA_WITH_AES_256_CBC_SHA - strong

|     compressors:

|       NULL

|_  least strength: strong

 

Does this get me any further down the road?

 

Thanks…

 

-- Bill

 

 

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Friday, October 28, 2016 3:48 PM
To: [hidden email]
Subject: Re: [dev-crypto] TlsClientProtocol and TLSv1.0

 

Hi Bill,

 

On 28/10/2016 8:28 PM, Bill Somerville wrote:

> Hi.  I'm running BC 1.55 on Java 6.  Recently, I had to start using

> TlsClientProtocol due to a site that went TLS 1.2 only, and the

> built-in Java 6 SSL stuff stopped working.  TlsClientProtocol is

> working great for sites with TLS 1.1 and TLS 1.2, however I have some

> internal sites that also run on Java 6, so only support TLS 1.0.

> Contacting these sites results in:

>

> java.io.IOException: Internal TLS error, this could be an attack

 

> Is TLS 1.0 disabled by default (and if so, how do I enable it), or is

> this some other problem?

 

The minimum version the client will accept is returned by

TlsClient.getMinimumVersion, which by default (AbstractTlsClient) is TLS

1.0. See also getClientVersion for the offered (maximum) version

(default TLS 1.2).

 

 

> Looking at the code, the stack trace doesn't make a lot of sense, but

> it would be kind of nice if failWithError() would include the cause

> when throwing this exception.  That is:

>

> throw new IOException(TLS_ERROR_MESSAGE);

>

> …would be more useful if it was (assuming cause is ever non-null):

>

> throw new IOException(TLS_ERROR_MESSAGE, cause);

 

The (somewhat weak) reason it's not passed is that the 'cause' parameter

is only available since 1.4, and we still support even earlier versions.

 

To get better information about the underlying error, I suggest

implementing the notifyAlertRaised method in your TlsClient

implementation, presumably a subclass of DefaultTlsClient. The 'cause'

is included as an argument to that call.

 

e.g. see

https://github.com/bcgit/bc-java/blob/master/core/src/test/java/org/bouncycastle/crypto/tls/test/MockTlsClient.java

 

If it's actually the server raising the error, implementing

notifyAlertReceived will let you see what type of alert it sent. If it

IS the server failing the handshake, the first thing to check is that

there is actually at least one ciphersuite in common b/w the

client/server configurations.

 

If you can post a followup with some of that information, it shouldn't

be too difficult to figure out what's wrong.

 

Regards,

Pete Dettman

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TlsClientProtocol and TLSv1.0

Peter Dettman-3

That's pretty straightforward; the server doesn't support secure
renegotiation (per RFC 5746). You could get past this by just overriding
the notifySecureRenegotiation method so that it does nothing (this would
be in your client class once again).

BC TLS doesn't implement renegotiation anyway, but this error is a sign
that you should disable renegotiation completely for the server.
https://tools.ietf.org/html/rfc5746#section-5 discusses some of the
security considerations.

Pete.

On 28/10/2016 11:29 PM, Bill Somerville wrote:

> Hi, Peter:
>
> Thanks for the response.  Here's what I get in notifyAlertRaised:
>
> Minimum version: TLS 1.0 (I display this from DefaultTlsClient.
> getMinimumVersion())
>
>
>
> notifyAlertRaised: alertLevel 2 alertDescription 40: Failed to read
> record
>
> org.bouncycastle.crypto.tls.TlsFatalAlert: handshake_failure(40)
>
> at
> org.bouncycastle.crypto.tls.AbstractTlsPeer.notifySecureRenegotiation(Unknown
>
>
Source)
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: TlsClientProtocol and TLSv1.0

Bill Somerville
Pete:
        Thanks - that did the trick.  FWIW, the purpose of this client is just to extract the cert chain from the server, so I'm not looking for full functionality.

-- Bill

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Friday, October 28, 2016 7:43 PM
To: [hidden email]
Subject: Re: [dev-crypto] TlsClientProtocol and TLSv1.0


That's pretty straightforward; the server doesn't support secure
renegotiation (per RFC 5746). You could get past this by just overriding
the notifySecureRenegotiation method so that it does nothing (this would
be in your client class once again).

BC TLS doesn't implement renegotiation anyway, but this error is a sign
that you should disable renegotiation completely for the server.
https://tools.ietf.org/html/rfc5746#section-5 discusses some of the
security considerations.

Pete.

On 28/10/2016 11:29 PM, Bill Somerville wrote:

> Hi, Peter:
>
> Thanks for the response.  Here's what I get in notifyAlertRaised:
>
> Minimum version: TLS 1.0 (I display this from DefaultTlsClient.
> getMinimumVersion())
>
>
>
> notifyAlertRaised: alertLevel 2 alertDescription 40: Failed to read
> record
>
> org.bouncycastle.crypto.tls.TlsFatalAlert: handshake_failure(40)
>
> at
> org.bouncycastle.crypto.tls.AbstractTlsPeer.notifySecureRenegotiation(Unknown
>
>
Source)
>


Loading...