Quantcast

Subject: PROBLEM WITH JSSE Provider

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

Subject: PROBLEM WITH JSSE Provider

Harinder Dang

Hi Bouncy !

 

 

I am using the JSSE Provider in the following configuration

 

java version "1.6.0_11"

Java(TM) SE Runtime Environment (build 1.6.0_11-b03)

Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode)

 

Apache Tomcat Version 6.0.41

JAX-WS RI 2.2.3

 

Added following Bouncy Castle jars -

bctls-jdk15on-156.jar

bcprov-jdk15on-156.jar

 

My code contains the following salient parts –

=====================================

 

Static {

          if (Security.getProvider(BouncyCastleJsseProvider.PROVIDER_NAME) == null) {

                Security.addProvider(new BouncyCastleJsseProvider());

            }

}

 

. . . . .

 

private static SSLContext getSslContext()  {

 

            SSLContext sslCtx = SSLContext.getInstance("TLS", BouncyCastleJsseProvider.PROVIDER_NAME);

            sslCtx.init(KEY_MANAGER …., TRUST_MANAGER…., new SecureRandom());

            return sslCtx;

}

 

. . . . .

   

       //SERVICE extends javax.xml.ws.Service;

       Portal port = SERVICE.getBasicHttpBindingPortal();

        BindingProvider bp = (BindingProvider)port;

        Map<String, Object> rc = bp.getRequestContext();

 

       // WEBSERVICES_URL  = https://xxxxx:13005/wsportal/n/ws/portal.asmx

        rc.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, Config.getDefaultValue(Config.Key.WEBSERVICES_URL));

        rc.put(JAXWSProperties.SSL_SOCKET_FACTORY, getSslContext().getSocketFactory());

 

However I am getting the following exception ….

 

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

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

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

        at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)

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

        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)

        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:415)

        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)

        at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:881)

        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)

        at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:120)

 

Please Help !!

 

I tried running a stand-alone program without JAXB , but I get the same exception …

 

       java.security.SecureRandom secureRandom = new java.security.SecureRandom();

       Socket socket = new Socket(java.net.InetAddress.getByName("www.google.com"), 443);

 

        TlsClientProtocol protocol = new TlsClientProtocol(socket.getInputStream(), socket.getOutputStream(),secureRandom);

 

        DefaultTlsClient client = new DefaultTlsClient() {

            public TlsAuthentication getAuthentication() throws IOException {

                TlsAuthentication auth = new TlsAuthentication() {

                    // Capture the server certificate information!

                    public void notifyServerCertificate(org.bouncycastle.crypto.tls.Certificate serverCertificate) throws IOException {

                    }

 

                    public TlsCredentials getClientCredentials(CertificateRequest certificateRequest) throws IOException {

                        return null;

                    }

                };

                return auth;

            }

        };

        protocol.connect(client);


Developer
SAI Global
Level 3, 355 Spencer Street West Melbourne, VIC  3003

T:  +61 3 9693 3507
E:  [hidden email]

http://www.saiglobal.com

 

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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
Hi Harinder,

Firstly, let me mention that BCJSSE will soon be getting some proper
logging, which should simplify diagnosing problems in future.

> Hi Bouncy !
>  
> I am using the JSSE Provider in the following configuration
<snip>
> Caused by: java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(Unknown Source)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
<snip>
> Please Help !!

This is kind of a generic exception, not giving much information.

However, the simplest and most likely problem here is that the server
doesn't support any of the default enabled ciphersuites in BCJSSE client.

Please find a definite ciphersuite that the server and client both
support and explicitly enable it. Also confirm that the server supports
TLS 1.2, or else you will need to enable an earlier version in the client.

> I tried running a stand-alone program without JAXB , but I get the same exception …
>  
>        java.security.SecureRandom secureRandom = new java.security.SecureRandom();
>        Socket socket = new Socket(java.net.InetAddress.getByName("www.google.com"), 443);
>  
>         TlsClientProtocol protocol = new TlsClientProtocol(socket.getInputStream(), socket.getOutputStream(),secureRandom);
>  
>         DefaultTlsClient client = new DefaultTlsClient() {
>             public TlsAuthentication getAuthentication() throws IOException {
>                 TlsAuthentication auth = new TlsAuthentication() {
>                     // Capture the server certificate information!
>                     public void notifyServerCertificate(org.bouncycastle.crypto.tls.Certificate serverCertificate) throws IOException {
>                     }
>  
>                     public TlsCredentials getClientCredentials(CertificateRequest certificateRequest) throws IOException {
>                         return null;
>                     }
>                 };
>                 return auth;
>             }
>         };
>         protocol.connect(client);

This test code works fine for me, please double-check at your end. If
you are still seeing an exception, please double-check basic
connectivity to www.google.com:443, then you can override (in your
DefaultTlsClient subclass) the notifyAlertRaised and notifyAlertReceived
methods to allow logging of the specific reason for the handshake failure.

Regards,
Pete Dettman


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

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
Hi Peter,

I've run into the same problem. Do you know when the improved logging will be available? I'm running 157b09.

I suspect the problem is as you say below that the ciphersuites aren't matching. Unfortunately I can't change what the server provides and the code I'm trying BC with is a legacy application where we don't have access to the source code to modify it :(

Is there a way to configure the defaults as part of the JRE?

Thanks,
Will

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Saturday, March 04, 2017 1:37 PM
To: BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi Harinder,

Firstly, let me mention that BCJSSE will soon be getting some proper logging, which should simplify diagnosing problems in future.

> Hi Bouncy !
>  
> I am using the JSSE Provider in the following configuration
<snip>
> Caused by: java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(Unknown Source)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown
> Source)
<snip>
> Please Help !!

This is kind of a generic exception, not giving much information.

However, the simplest and most likely problem here is that the server doesn't support any of the default enabled ciphersuites in BCJSSE client.

Please find a definite ciphersuite that the server and client both support and explicitly enable it. Also confirm that the server supports TLS 1.2, or else you will need to enable an earlier version in the client.

> I tried running a stand-alone program without JAXB , but I get the
> same exception ...
>  
>        java.security.SecureRandom secureRandom = new java.security.SecureRandom();
>        Socket socket = new
> Socket(java.net.InetAddress.getByName("www.google.com"), 443);
>  
>         TlsClientProtocol protocol = new
> TlsClientProtocol(socket.getInputStream(),
> socket.getOutputStream(),secureRandom);
>  
>         DefaultTlsClient client = new DefaultTlsClient() {
>             public TlsAuthentication getAuthentication() throws IOException {
>                 TlsAuthentication auth = new TlsAuthentication() {
>                     // Capture the server certificate information!
>                     public void notifyServerCertificate(org.bouncycastle.crypto.tls.Certificate serverCertificate) throws IOException {
>                     }
>  
>                     public TlsCredentials getClientCredentials(CertificateRequest certificateRequest) throws IOException {
>                         return null;
>                     }
>                 };
>                 return auth;
>             }
>         };
>         protocol.connect(client);

This test code works fine for me, please double-check at your end. If you are still seeing an exception, please double-check basic connectivity to www.google.com:443, then you can override (in your DefaultTlsClient subclass) the notifyAlertRaised and notifyAlertReceived methods to allow logging of the specific reason for the handshake failure.

Regards,
Pete Dettman



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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
Hi William,

On 25/03/2017 12:42 AM, William Konitzer wrote:
> Hi Peter,
>
> I've run into the same problem. Do you know when the improved logging
> will be available? I'm running 157b09.

We've already added (in git at least) some minimal initial logging (via
the Java Logging API). It will be fleshed out in due course, but already
gives you stack traces for locally raised alerts.

>
> I suspect the problem is as you say below that the ciphersuites
> aren't matching. Unfortunately I can't change what the server
> provides and the code I'm trying BC with is a legacy application
> where we don't have access to the source code to modify it :(

IIUC that you are using a BC client to a server with fixed ciphersuite
selection, then note that the logging won't help a whole lot anyway,
since the only information the client gets from the server after a
ciphersuite mismatch is a fatal handshake_failure alert (which is logged
by the client).

I can't speak to other servers, but for our TLS server code, a
handshake_failure could mean any of at least:

- client does not support secure renegotiation (RFC 5746)
- no ciphersuite or compression method could be agreed upon
- missing required client authentication
- input closed or close_notify alert received during handshake

Ciphersuite should definitely be checked first, but you may end up
needing to look at the server logs (and/or wireshark).

>
> Is there a way to configure the defaults as part of the JRE?

I don't think so, but we will be extending the default list of
ciphersuites in BCJSSE shortly in any case. Please feel free to nominate
particular ciphersuites that you would like to see included.

Regards,
Pete Dettman


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

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
Hi Peter,

I did some digging with wireshark and the TLS handshake is failing because of a ciphersuite mismatch, as suspected.

Running some tests against the server it seems to support the following

AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
CAMELLIA256-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
SEED-SHA
CAMELLIA128-SHA
DES-CBC3-SHA
IDEA-CBC-SHA
RC4-SHA

Also, it would appear the server has a preference for RC4-SHA (which seems not so good given rfc7465?). Are any of the above supported by BC and could one be added as a default in the next beta build of the JSSE for me to test?

Note the names are the openssl cipher names, I'm not sure how that maps to bouncy castle ciphers.

Regards,
Will

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Saturday, March 25, 2017 3:19 AM
To: BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi William,

On 25/03/2017 12:42 AM, William Konitzer wrote:
> Hi Peter,
>
> I've run into the same problem. Do you know when the improved logging
> will be available? I'm running 157b09.

We've already added (in git at least) some minimal initial logging (via the Java Logging API). It will be fleshed out in due course, but already gives you stack traces for locally raised alerts.

>
> I suspect the problem is as you say below that the ciphersuites aren't
> matching. Unfortunately I can't change what the server provides and
> the code I'm trying BC with is a legacy application where we don't
> have access to the source code to modify it :(

IIUC that you are using a BC client to a server with fixed ciphersuite selection, then note that the logging won't help a whole lot anyway, since the only information the client gets from the server after a ciphersuite mismatch is a fatal handshake_failure alert (which is logged by the client).

I can't speak to other servers, but for our TLS server code, a handshake_failure could mean any of at least:

- client does not support secure renegotiation (RFC 5746)
- no ciphersuite or compression method could be agreed upon
- missing required client authentication
- input closed or close_notify alert received during handshake

Ciphersuite should definitely be checked first, but you may end up needing to look at the server logs (and/or wireshark).

>
> Is there a way to configure the defaults as part of the JRE?

I don't think so, but we will be extending the default list of ciphersuites in BCJSSE shortly in any case. Please feel free to nominate particular ciphersuites that you would like to see included.

Regards,
Pete Dettman



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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
Hi William,
If https://testssl.sh/openssl-rfc.mappping.html is anything to go by, it
appears all these cipher suites are using RSA key exchange. We'll look
at adding a few of the AES ones for the next beta.

Yeah, RC4-SHA is not a great idea, also DES-CBC3-SHA
(https://sweet32.info) and IDEA-CBC-SHA
(https://tools.ietf.org/html/rfc5469, but also 64-bit blocks, so sweet32
presumably applies).

We actually have some 3DES (DES-CBC3-SHA) cipher suites in our supported
list since many people are going to need them, but they will never be
enabled by default.

Regards,
Pete Dettman

On 30/03/2017 10:24 AM, William Konitzer wrote:

> Hi Peter,
>
> I did some digging with wireshark and the TLS handshake is failing because of a ciphersuite mismatch, as suspected.
>
> Running some tests against the server it seems to support the following
>
> AES256-GCM-SHA384
> AES256-SHA256
> AES256-SHA
> CAMELLIA256-SHA
> AES128-GCM-SHA256
> AES128-SHA256
> AES128-SHA
> SEED-SHA
> CAMELLIA128-SHA
> DES-CBC3-SHA
> IDEA-CBC-SHA
> RC4-SHA
>
> Also, it would appear the server has a preference for RC4-SHA (which seems not so good given rfc7465?). Are any of the above supported by BC and could one be added as a default in the next beta build of the JSSE for me to test?
>
> Note the names are the openssl cipher names, I'm not sure how that maps to bouncy castle ciphers.
>
> Regards,
> Will


Loading...