Quantcast

Subject: PROBLEM WITH JSSE Provider

classic Classic list List threaded Threaded
17 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


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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
In reply to this post by William Konitzer
Hi William,
A new beta version is available at:
    https://downloads.bouncycastle.org/betas/

BCJSSE's default cipher suites now include several using ECDHE_ECDSA and
RSA key exchange, plus a few more ECDHE_RSA ones. Current list:

            "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
            "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
            "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
            "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
            "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
            "TLS_RSA_WITH_AES_256_GCM_SHA384",
            "TLS_RSA_WITH_AES_128_GCM_SHA256",
            "TLS_RSA_WITH_AES_256_CBC_SHA256",
            "TLS_RSA_WITH_AES_128_CBC_SHA256",
            "TLS_RSA_WITH_AES_256_CBC_SHA",
            "TLS_RSA_WITH_AES_128_CBC_SHA",

All 6 of the RSA cipher suites are in your list below. so you should be
able to get past cipher suite negotiation now.

Regards,
Pete Dettman

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

> 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


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

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
Hi Peter,

Yes, that gets me passed the handshake error :)

Now I'm hitting a different problem :( After the server sends "CertificateServer Hello done", my client (i.e. BC) sends "Alert (Level: Fatal, Description: Internal Error (80)".

Any idea what could be the issue now? Here's the stack trace.

java.io.IOException: Internal TLS error, this could be an attack
        at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:592)
        at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
        at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)

I've also attached the packet capture in case it's helpful.

Regards,
Will


-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Sunday, April 02, 2017 1:23 AM
To: BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi William,
A new beta version is available at:
    https://downloads.bouncycastle.org/betas/

BCJSSE's default cipher suites now include several using ECDHE_ECDSA and RSA key exchange, plus a few more ECDHE_RSA ones. Current list:

            "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
            "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
            "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
            "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
            "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
            "TLS_RSA_WITH_AES_256_GCM_SHA384",
            "TLS_RSA_WITH_AES_128_GCM_SHA256",
            "TLS_RSA_WITH_AES_256_CBC_SHA256",
            "TLS_RSA_WITH_AES_128_CBC_SHA256",
            "TLS_RSA_WITH_AES_256_CBC_SHA",
            "TLS_RSA_WITH_AES_128_CBC_SHA",

All 6 of the RSA cipher suites are in your list below. so you should be able to get past cipher suite negotiation now.

Regards,
Pete Dettman

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

> 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



tls_error.pcap (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
In reply to this post by Peter Dettman-3
Hi Peter,

Any thoughts on what could be going wrong here?

Thanks,
Will

-----Original Message-----
From: William Konitzer
Sent: Sunday, April 02, 2017 2:44 AM
To: '[hidden email]' <[hidden email]>; BouncyCastle <[hidden email]>
Subject: RE: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi Peter,

Yes, that gets me passed the handshake error :)

Now I'm hitting a different problem :( After the server sends "CertificateServer Hello done", my client (i.e. BC) sends "Alert (Level: Fatal, Description: Internal Error (80)".

Any idea what could be the issue now? Here's the stack trace.

java.io.IOException: Internal TLS error, this could be an attack
        at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:592)
        at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
        at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)

I've also attached the packet capture in case it's helpful.

Regards,
Will


-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Sunday, April 02, 2017 1:23 AM
To: BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi William,
A new beta version is available at:
    https://downloads.bouncycastle.org/betas/

BCJSSE's default cipher suites now include several using ECDHE_ECDSA and RSA key exchange, plus a few more ECDHE_RSA ones. Current list:

            "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
            "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
            "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
            "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
            "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
            "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
            "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
            "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
            "TLS_RSA_WITH_AES_256_GCM_SHA384",
            "TLS_RSA_WITH_AES_128_GCM_SHA256",
            "TLS_RSA_WITH_AES_256_CBC_SHA256",
            "TLS_RSA_WITH_AES_128_CBC_SHA256",
            "TLS_RSA_WITH_AES_256_CBC_SHA",
            "TLS_RSA_WITH_AES_128_CBC_SHA",

All 6 of the RSA cipher suites are in your list below. so you should be able to get past cipher suite negotiation now.

Regards,
Pete Dettman

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

> 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



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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
Hi Will,
If you are using the latest beta, you ought to be seeing (or be able to
configure somehow) Java Logging output. I would have expected the alert
you report to have been logged at Level.WARNING (to System.err?), and
would include the underlying exception's stack trace.

There's quite a few things that could be potentially wrong at this point
so if you can get that stack trace, it will be a lot easier than
guessing things.

Regards,
Pete Dettman

On 7/04/2017 2:55 AM, William Konitzer wrote:

> Hi Peter,
>
> Any thoughts on what could be going wrong here?
>
> Thanks,
> Will
>
> -----Original Message-----
> From: William Konitzer
> Sent: Sunday, April 02, 2017 2:44 AM
> To: '[hidden email]' <[hidden email]>; BouncyCastle <[hidden email]>
> Subject: RE: [dev-crypto] Subject: PROBLEM WITH JSSE Provider
>
> Hi Peter,
>
> Yes, that gets me passed the handshake error :)
>
> Now I'm hitting a different problem :( After the server sends "CertificateServer Hello done", my client (i.e. BC) sends "Alert (Level: Fatal, Description: Internal Error (80)".
>
> Any idea what could be the issue now? Here's the stack trace.
>
> java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:592)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
>         at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)
>
> I've also attached the packet capture in case it's helpful.
>
> Regards,
> Will


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

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
Hi Peter,

I think I found the log - does this give you what you need?

Apr 2, 2017 3:33:48 AM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
WARNING: Client raised fatal(2) internal_error(80) alert: Failed to read record
java.lang.NullPointerException: the keystore parameter must be non-null
        at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:128)
        at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:113)
        at org.bouncycastle.jsse.provider.ProvX509TrustManager.validatePath(ProvX509TrustManager.java:90)
        at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(ProvX509TrustManager.java:48)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.isServerTrusted(ProvSSLSocketDirect.java:333)
        at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(ProvTlsClient.java:191)
        at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(TlsClientProtocol.java:179)
        at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(TlsProtocol.java:376)
        at org.bouncycastle.tls.TlsProtocol.processRecord(TlsProtocol.java:294)
        at org.bouncycastle.tls.RecordStream.readRecord(RecordStream.java:222)
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:563)
        at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
        at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:286)
        at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)

Thanks,
Will

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Saturday, April 08, 2017 12:50 PM
To: BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi Will,
If you are using the latest beta, you ought to be seeing (or be able to configure somehow) Java Logging output. I would have expected the alert you report to have been logged at Level.WARNING (to System.err?), and would include the underlying exception's stack trace.

There's quite a few things that could be potentially wrong at this point so if you can get that stack trace, it will be a lot easier than guessing things.

Regards,
Pete Dettman

On 7/04/2017 2:55 AM, William Konitzer wrote:

> Hi Peter,
>
> Any thoughts on what could be going wrong here?
>
> Thanks,
> Will
>
> -----Original Message-----
> From: William Konitzer
> Sent: Sunday, April 02, 2017 2:44 AM
> To: '[hidden email]' <[hidden email]>;
> BouncyCastle <[hidden email]>
> Subject: RE: [dev-crypto] Subject: PROBLEM WITH JSSE Provider
>
> Hi Peter,
>
> Yes, that gets me passed the handshake error :)
>
> Now I'm hitting a different problem :( After the server sends "CertificateServer Hello done", my client (i.e. BC) sends "Alert (Level: Fatal, Description: Internal Error (80)".
>
> Any idea what could be the issue now? Here's the stack trace.
>
> java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:592)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
>         at
> org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:
> 102)
>
> I've also attached the packet capture in case it's helpful.
>
> Regards,
> Will



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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
Hi William,
Thanks for collecting that. I think it's clear that the problem lies
with our trust manager not supporting default initialization yet
(presumably from the cacerts file in the JRE or some env-var/sys-prop
-defined alternative).

Looking at the Apache Axis code here:

http://svn.apache.org/viewvc/axis/axis1/java/trunk/axis-rt-core/src/main/java/org/apache/axis/components/net/JSSESocketFactory.java?view=markup

we see it uses:
    SSLSocketFactory.getDefault() (line 61)

which according to javadoc is effectively:
    SSLContext.getDefault().getSocketFactory()

There was a brief exchange about the default SSLContext a few weeks back
on this list, but it's not fixed yet. We'll try to sort it out for the
next beta release, which should be a few days away.

Regards,
Pete Dettman


On 9/04/2017 1:28 AM, William Konitzer wrote:

> Hi Peter,
>
> I think I found the log - does this give you what you need?
>
> Apr 2, 2017 3:33:48 AM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
> WARNING: Client raised fatal(2) internal_error(80) alert: Failed to read record
> java.lang.NullPointerException: the keystore parameter must be non-null
>         at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:128)
>         at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:113)
>         at org.bouncycastle.jsse.provider.ProvX509TrustManager.validatePath(ProvX509TrustManager.java:90)
>         at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(ProvX509TrustManager.java:48)
>         at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.isServerTrusted(ProvSSLSocketDirect.java:333)
>         at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(ProvTlsClient.java:191)
>         at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(TlsClientProtocol.java:179)
>         at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(TlsProtocol.java:376)
>         at org.bouncycastle.tls.TlsProtocol.processRecord(TlsProtocol.java:294)
>         at org.bouncycastle.tls.RecordStream.readRecord(RecordStream.java:222)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:563)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
>         at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)
>         at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:286)
>         at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
>
> Thanks,
> Will


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

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
Hi Peter,

Thanks for the new beta, but unfortunately it doesn't seem to work :(

With bcprov-jdk15on-157b12.jar and bctls-jdk15on-157b12.jar I get

{http://xml.apache.org/axis/}stackTrace:java.io.IOException: Internal TLS error, this could be an attack
        at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:592)
        at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
        at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:286)
        at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
        at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)
       

but with bcprov-jdk15on-157b13.jar and bctls-jdk15on-157b13.jar I get

{http://xml.apache.org/axis/}stackTrace:java.net.SocketException: java.security.NoSuchAlgorithmException: No such algorithm in FIPS approved mode: DEFAULT
        at javax.net.ssl.DefaultSSLSocketFactory.throwException(SSLSocketFactory.java:179)
        at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:192)
        at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:92)
        at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)

so it looks like the BCJSSE is never getting called. Given that the only thing I changed was the two library files it feels like something is not right in the BC libs. Thoughts?      

For reference my security provider list looks like
security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.4=sun.security.jgss.SunProvider
security.provider.5=com.sun.security.sasl.Provider
security.provider.6=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.7=sun.security.smartcardio.SunPCSC

Thanks,
Will

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Sunday, April 09, 2017 11:15 AM
To: BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi William,
Thanks for collecting that. I think it's clear that the problem lies with our trust manager not supporting default initialization yet (presumably from the cacerts file in the JRE or some env-var/sys-prop -defined alternative).

Looking at the Apache Axis code here:

http://svn.apache.org/viewvc/axis/axis1/java/trunk/axis-rt-core/src/main/java/org/apache/axis/components/net/JSSESocketFactory.java?view=markup

we see it uses:
    SSLSocketFactory.getDefault() (line 61)

which according to javadoc is effectively:
    SSLContext.getDefault().getSocketFactory()

There was a brief exchange about the default SSLContext a few weeks back on this list, but it's not fixed yet. We'll try to sort it out for the next beta release, which should be a few days away.

Regards,
Pete Dettman


On 9/04/2017 1:28 AM, William Konitzer wrote:

> Hi Peter,
>
> I think I found the log - does this give you what you need?
>
> Apr 2, 2017 3:33:48 AM org.bouncycastle.jsse.provider.ProvTlsClient
> notifyAlertRaised
> WARNING: Client raised fatal(2) internal_error(80) alert: Failed to
> read record
> java.lang.NullPointerException: the keystore parameter must be non-null
>         at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:128)
>         at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:113)
>         at org.bouncycastle.jsse.provider.ProvX509TrustManager.validatePath(ProvX509TrustManager.java:90)
>         at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(ProvX509TrustManager.java:48)
>         at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.isServerTrusted(ProvSSLSocketDirect.java:333)
>         at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(ProvTlsClient.java:191)
>         at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(TlsClientProtocol.java:179)
>         at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(TlsProtocol.java:376)
>         at org.bouncycastle.tls.TlsProtocol.processRecord(TlsProtocol.java:294)
>         at org.bouncycastle.tls.RecordStream.readRecord(RecordStream.java:222)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:563)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
>         at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)
>         at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:286)
>         at
> org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFact
> ory.java:186)
>
> Thanks,
> Will



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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
Hi William,
Firstly, the exception message is some sort of copy/paste error and has
nothing to do with FIPS. We'll fix that and improve the logging for this
scenario.

By removing the SunJSSE provider (com.sun.net.ssl.internal.ssl.Provider)
you have removed the only provider for "SunX509" KeyManagerFactory (we
are reluctant to support algorithm names involving "Sun" - perhaps this
is overly paranoid?). "SunX509" also happens to be the default KMF
algorithm and so BC is (correctly) attempting to instantiate a SunX509
KMF to initialize the default SSLContext.

There are 2 solutions here:
1) Modify the default KMF algorithm so that it will be one that BCJSSE
supports, by changing the java.security property:
    ssl.KeyManagerFactory.algorithm=X509
2) Re-add the SunJSSE provider somewhere in the list (presumably after
the BCJSSE one if you just want it as a fallback).

I think the first is preferable for now, since it will also avoid any
incompatibilities that may yet exist b/w the 2 JSSE providers.

Regards,
Pete Dettman


On 12/04/2017 1:49 PM, William Konitzer wrote:

> Hi Peter,
>
> Thanks for the new beta, but unfortunately it doesn't seem to work :(
>
> With bcprov-jdk15on-157b12.jar and bctls-jdk15on-157b12.jar I get
>
> {http://xml.apache.org/axis/}stackTrace:java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:592)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
>         at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)
>         at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:286)
>         at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
>         at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)
>        
>
> but with bcprov-jdk15on-157b13.jar and bctls-jdk15on-157b13.jar I get
>
> {http://xml.apache.org/axis/}stackTrace:java.net.SocketException: java.security.NoSuchAlgorithmException: No such algorithm in FIPS approved mode: DEFAULT
>         at javax.net.ssl.DefaultSSLSocketFactory.throwException(SSLSocketFactory.java:179)
>         at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:192)
>         at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:92)
>         at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)
>
> so it looks like the BCJSSE is never getting called. Given that the only thing I changed was the two library files it feels like something is not right in the BC libs. Thoughts?      
>
> For reference my security provider list looks like
> security.provider.1=sun.security.provider.Sun
> security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
> security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider
> security.provider.4=sun.security.jgss.SunProvider
> security.provider.5=com.sun.security.sasl.Provider
> security.provider.6=org.jcp.xml.dsig.internal.dom.XMLDSigRI
> security.provider.7=sun.security.smartcardio.SunPCSC
>
> Thanks,
> Will


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

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
Hi Peter,

Thanks for the quick response. In the java.security file I changed

ssl.KeyManagerFactory.algorithm=PKIK

and we seem to be getting further. I'm still receiving the following in my application

        {http://xml.apache.org/axis/}stackTrace:java.io.IOException: Internal TLS error, this could be an attack
        at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:584)

The actual error coming out of BC is as follows.

Apr 12, 2017 3:35:46 AM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
WARNING: Client raised fatal(2) internal_error(80) alert: Failed to read record
org.bouncycastle.tls.TlsNoCloseNotifyException
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:569)
        at org.bouncycastle.tls.TlsProtocol.readApplicationData(TlsProtocol.java:526)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect$AppDataInput.read(ProvSSLSocketDirect.java:409)

 A quick check of the BC code suggests this only gets thrown if the connection is closed and sure enough I see a TCP FIN in the packet before.

Is this an error on the side of the Server? Taking a quick look at RFC 5246 suggests it's behaving incorrectly and I need to get the server side fixed. Is that your understanding as well?

-Will

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Wednesday, April 12, 2017 3:19 AM
To: William Konitzer <[hidden email]>; BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi William,
Firstly, the exception message is some sort of copy/paste error and has nothing to do with FIPS. We'll fix that and improve the logging for this scenario.

By removing the SunJSSE provider (com.sun.net.ssl.internal.ssl.Provider)
you have removed the only provider for "SunX509" KeyManagerFactory (we are reluctant to support algorithm names involving "Sun" - perhaps this is overly paranoid?). "SunX509" also happens to be the default KMF algorithm and so BC is (correctly) attempting to instantiate a SunX509 KMF to initialize the default SSLContext.

There are 2 solutions here:
1) Modify the default KMF algorithm so that it will be one that BCJSSE supports, by changing the java.security property:
    ssl.KeyManagerFactory.algorithm=X509
2) Re-add the SunJSSE provider somewhere in the list (presumably after the BCJSSE one if you just want it as a fallback).

I think the first is preferable for now, since it will also avoid any incompatibilities that may yet exist b/w the 2 JSSE providers.

Regards,
Pete Dettman


On 12/04/2017 1:49 PM, William Konitzer wrote:

> Hi Peter,
>
> Thanks for the new beta, but unfortunately it doesn't seem to work :(
>
> With bcprov-jdk15on-157b12.jar and bctls-jdk15on-157b12.jar I get
>
> {http://xml.apache.org/axis/}stackTrace:java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:592)
>         at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:194)
>         at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:102)
>         at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:286)
>         at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
>         at
> org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:19
> 1)
>        
>
> but with bcprov-jdk15on-157b13.jar and bctls-jdk15on-157b13.jar I get
>
> {http://xml.apache.org/axis/}stackTrace:java.net.SocketException: java.security.NoSuchAlgorithmException: No such algorithm in FIPS approved mode: DEFAULT
>         at javax.net.ssl.DefaultSSLSocketFactory.throwException(SSLSocketFactory.java:179)
>         at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:192)
>         at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:92)
>         at
> org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:19
> 1)
>
> so it looks like the BCJSSE is never getting called. Given that the only thing I changed was the two library files it feels like something is not right in the BC libs. Thoughts?      
>
> For reference my security provider list looks like
> security.provider.1=sun.security.provider.Sun
> security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJssePro
> vider
> security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider
> security.provider.4=sun.security.jgss.SunProvider
> security.provider.5=com.sun.security.sasl.Provider
> security.provider.6=org.jcp.xml.dsig.internal.dom.XMLDSigRI
> security.provider.7=sun.security.smartcardio.SunPCSC
>
> Thanks,
> Will


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

Re: Subject: PROBLEM WITH JSSE Provider

Peter Dettman-3
Hi William,
So it appears the handshake is completing successfully - do you know if
your application is successfully exchanging application data after the
handshake?

The TlsNoCloseNotifyException is a specific complaint that the peer did
not send a close_notify alert prior to closing its end of the connection
(possible truncation attack). It's a murky area, as it seems not all TLS
implementations think it's important to implement this correctly (both
on the sending side and on the "complaining" side). See also my answer
here:
http://stackoverflow.com/questions/40636982/how-to-detect-an-end-of-stream-properly-when-tls-psk-encryption-is-used/42324209#42324209
.

In any case, at least identify the server software involved and see if
you can find out why it doesn't send close_notify. In the meantime, you
should be able to continue testing by just treating this exception as a
normal EOF (I don't recommend keeping that for production code unless
the server situation leaves you no choice AND you have a way of
preventing truncation in your application protocol).

Regards,
Pete Dettman


On 12/04/2017 4:02 PM, William Konitzer wrote:

> Hi Peter,
>
> Thanks for the quick response. In the java.security file I changed
>
> ssl.KeyManagerFactory.algorithm=PKIK
>
> and we seem to be getting further. I'm still receiving the following in my application
>
>         {http://xml.apache.org/axis/}stackTrace:java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:584)
>
> The actual error coming out of BC is as follows.
>
> Apr 12, 2017 3:35:46 AM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
> WARNING: Client raised fatal(2) internal_error(80) alert: Failed to read record
> org.bouncycastle.tls.TlsNoCloseNotifyException
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:569)
>         at org.bouncycastle.tls.TlsProtocol.readApplicationData(TlsProtocol.java:526)
>         at org.bouncycastle.jsse.provider.ProvSSLSocketDirect$AppDataInput.read(ProvSSLSocketDirect.java:409)
>
>  A quick check of the BC code suggests this only gets thrown if the connection is closed and sure enough I see a TCP FIN in the packet before.
>
> Is this an error on the side of the Server? Taking a quick look at RFC 5246 suggests it's behaving incorrectly and I need to get the server side fixed. Is that your understanding as well?
>
> -Will


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

RE: Subject: PROBLEM WITH JSSE Provider

William Konitzer
Hi Peter,

The 2nd answer here:

https://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify

suggests that for a webservice like mine, the close_notify isn't required as the application protocol is self-terminating, so treating as an EOF as you suggest is probably the correct thing to do! (However, that probably doesn't help me much as this is a legacy app and getting hold of the source code is proving difficult).

I appreciate all the help.

Regards,
Will

-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Wednesday, April 12, 2017 4:51 AM
To: William Konitzer <[hidden email]>; BouncyCastle <[hidden email]>
Subject: Re: [dev-crypto] Subject: PROBLEM WITH JSSE Provider

Hi William,
So it appears the handshake is completing successfully - do you know if your application is successfully exchanging application data after the handshake?

The TlsNoCloseNotifyException is a specific complaint that the peer did not send a close_notify alert prior to closing its end of the connection (possible truncation attack). It's a murky area, as it seems not all TLS implementations think it's important to implement this correctly (both on the sending side and on the "complaining" side). See also my answer
here:
http://stackoverflow.com/questions/40636982/how-to-detect-an-end-of-stream-properly-when-tls-psk-encryption-is-used/42324209#42324209
.

In any case, at least identify the server software involved and see if you can find out why it doesn't send close_notify. In the meantime, you should be able to continue testing by just treating this exception as a normal EOF (I don't recommend keeping that for production code unless the server situation leaves you no choice AND you have a way of preventing truncation in your application protocol).

Regards,
Pete Dettman


On 12/04/2017 4:02 PM, William Konitzer wrote:

> Hi Peter,
>
> Thanks for the quick response. In the java.security file I changed
>
> ssl.KeyManagerFactory.algorithm=PKIK
>
> and we seem to be getting further. I'm still receiving the following
> in my application
>
>         {http://xml.apache.org/axis/}stackTrace:java.io.IOException: Internal TLS error, this could be an attack
>         at org.bouncycastle.tls.TlsProtocol.failWithError(TlsProtocol.java:989)
>         at
> org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:584)
>
> The actual error coming out of BC is as follows.
>
> Apr 12, 2017 3:35:46 AM org.bouncycastle.jsse.provider.ProvTlsClient
> notifyAlertRaised
> WARNING: Client raised fatal(2) internal_error(80) alert: Failed to
> read record org.bouncycastle.tls.TlsNoCloseNotifyException
>         at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:569)
>         at org.bouncycastle.tls.TlsProtocol.readApplicationData(TlsProtocol.java:526)
>         at
> org.bouncycastle.jsse.provider.ProvSSLSocketDirect$AppDataInput.read(P
> rovSSLSocketDirect.java:409)
>
>  A quick check of the BC code suggests this only gets thrown if the connection is closed and sure enough I see a TCP FIN in the packet before.
>
> Is this an error on the side of the Server? Taking a quick look at RFC 5246 suggests it's behaving incorrectly and I need to get the server side fixed. Is that your understanding as well?
>
> -Will


Loading...