Does BC actually provide cipher suites unavailable in Java 7?

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

Does BC actually provide cipher suites unavailable in Java 7?

DiBaggio, Michael

Hi everyone. I haven’t pestered this list with my questions for several years, but I’m in a bind again.

 

I am supporting a product that, for now, is absolutely restricted to Java 7. However, we have an application that connects to NetSuite, and about a week ago, NetSuite stopped allowing access to any of the ciphersuites we support out of the box.

 

The ones we need to support are:

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • AES128-GCM-SHA256
  • AES256-GCM-SHA384

None of which are available in Java 7.

 

I copied the latest BCprov and BCtls jars into my jre/lib/ext, updated the java.security to list org.bouncycastle.jce.provider.BouncyCastleProvider and org.bouncycastle.jsse.provider.BouncyCastleJsseProvider as my first and second providers, and loaded the unlimited strength crypto policy jars. I then added the following arguments when I launch the application:

-Dhttps.protocols=TLSv1.2

-Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

 

But I get an “unsupported cipher” exception.

 

So now I’m wondering if BC will actually provide ciphers it knows about if the underlying JRE doesn’t support them. On the other hand, if it is possible, I would appreciate some advice.

 

Regards,

Mike

Michael 
DiBaggio
Cleo  |  
Sr Software Engineer II
  
 
Email: [hidden email]
  |  
Web: www.cleo.com
  
  
Join us for Cleo Connect 2019, October 7-10 in Orlando!  Register today!
 
 
Reply | Threaded
Open this post in threaded view
|

AW: Does BC actually provide cipher suites unavailable in Java 7?

Eckenfels. Bernd

Hello,

 

IMHO you cannot add new ciphers to the existing JSSE provider (you can only replace existing implementations). So when you want to use BC for new ciphers you will also have to switch to the SSL implementations of BC.

 

Gruss

Bernd

 

Von: DiBaggio, Michael <[hidden email]>
Gesendet: Montag, 1. Juli 2019 16:14
An: [hidden email]
Betreff: [dev-crypto] Does BC actually provide cipher suites unavailable in Java 7?

 

Hi everyone. I haven’t pestered this list with my questions for several years, but I’m in a bind again.

 

I am supporting a product that, for now, is absolutely restricted to Java 7. However, we have an application that connects to NetSuite, and about a week ago, NetSuite stopped allowing access to any of the ciphersuites we support out of the box.

 

The ones we need to support are:

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • AES128-GCM-SHA256
  • AES256-GCM-SHA384

None of which are available in Java 7.

 

I copied the latest BCprov and BCtls jars into my jre/lib/ext, updated the java.security to list org.bouncycastle.jce.provider.BouncyCastleProvider and org.bouncycastle.jsse.provider.BouncyCastleJsseProvider as my first and second providers, and loaded the unlimited strength crypto policy jars. I then added the following arguments when I launch the application:

-Dhttps.protocols=TLSv1.2

-Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

 

But I get an “unsupported cipher” exception.

 

So now I’m wondering if BC will actually provide ciphers it knows about if the underlying JRE doesn’t support them. On the other hand, if it is possible, I would appreciate some advice.

 

Regards,

Mike

Michael

 

DiBaggio

Cleo

  |  

Sr Software Engineer II

 

 

 

Email: 

[hidden email]

  |  

Web: 

www.cleo.com

 

 

 

 

Join us for Cleo Connect 2019, October 7-10 in Orlando!  Register today!

 

 

 






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: Does BC actually provide cipher suites unavailable in Java 7?

Lothar Kimmeringer-4
In reply to this post by DiBaggio, Michael


Am 01.07.2019 um 16:14 schrieb DiBaggio, Michael:

> So now I’m wondering if BC will actually provide ciphers it knows about if the
> underlying JRE doesn’t support them. On the other hand, if it is possible, I
> would appreciate some advice.

An immediate solution and in case there is no solution for Java, you can use
e.g. stunnel to do the TLS for your application.


Cheers, Lothar

Reply | Threaded
Open this post in threaded view
|

Re: AW: Does BC actually provide cipher suites unavailable in Java 7?

Luca Mambretti
In reply to this post by Eckenfels. Bernd
You could try something like this:

    BouncyCastleJsseProvider provider = new BouncyCastleJsseProvider(new BouncyCastleProvider());
    SSLContext sslContext = SSLContext.getInstance("TLS", provider);
    sslContext.init(null, null, new SecureRandom());
    SSLSocketFactory fact = sslContext.getSocketFactory();
    HttpsURLConnection conn = (HttpsURLConnection) new URL("https://[URL_THAT_REQUIRES_YOUR_CIPHERS]").openConnection();
    conn.setSSLSocketFactory(fact);
    conn.connect();
    InputStream is = conn.getInputStream();

this should bypass all of the JRE default initialization logic and give you a BC powered SSLContext to work with, the URL connection is actually just a quick way to test it actually works, I've been able to get a working connection with JRE 1.6 using this method while the OutOfTheBox implementation was unable to connect to the very same URL.

Regards
Luca Mambretti

Da: "Eckenfels. Bernd" <[hidden email]>
A: [hidden email]
Inviato: Lunedì, 1 luglio 2019 16:27:50
Oggetto: [dev-crypto] AW: Does BC actually provide cipher suites unavailable in Java 7?

Hello,

 

IMHO you cannot add new ciphers to the existing JSSE provider (you can only replace existing implementations). So when you want to use BC for new ciphers you will also have to switch to the SSL implementations of BC.

 

Gruss

Bernd

 

Von: DiBaggio, Michael <[hidden email]>
Gesendet: Montag, 1. Juli 2019 16:14
An: [hidden email]
Betreff: [dev-crypto] Does BC actually provide cipher suites unavailable in Java 7?

 

Hi everyone. I haven’t pestered this list with my questions for several years, but I’m in a bind again.

 

I am supporting a product that, for now, is absolutely restricted to Java 7. However, we have an application that connects to NetSuite, and about a week ago, NetSuite stopped allowing access to any of the ciphersuites we support out of the box.

 

The ones we need to support are:

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • AES128-GCM-SHA256
  • AES256-GCM-SHA384

None of which are available in Java 7.

 

I copied the latest BCprov and BCtls jars into my jre/lib/ext, updated the java.security to list org.bouncycastle.jce.provider.BouncyCastleProvider and org.bouncycastle.jsse.provider.BouncyCastleJsseProvider as my first and second providers, and loaded the unlimited strength crypto policy jars. I then added the following arguments when I launch the application:

-Dhttps.protocols=TLSv1.2

-Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

 

But I get an “unsupported cipher” exception.

 

So now I’m wondering if BC will actually provide ciphers it knows about if the underlying JRE doesn’t support them. On the other hand, if it is possible, I would appreciate some advice.

 

Regards,

Mike

Michael

 

DiBaggio

Cleo

  |  

Sr Software Engineer II

 

 

 

Email: 

[hidden email]

  |  

Web: 

www.cleo.com

 

 

 

 

Join us for Cleo Connect 2019, October 7-10 in Orlando!  Register today!

 

 

 






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.


Reply | Threaded
Open this post in threaded view
|

Re: Does BC actually provide cipher suites unavailable in Java 7?

Peter Dettman-3
In reply to this post by DiBaggio, Michael
Hi Michael,

Responses inline:

On 1/7/19 9:14 pm, DiBaggio, Michael wrote:

> Hi everyone. I haven’t pestered this list with my questions for several
> years, but I’m in a bind again.
>
> I am supporting a product that, for now, is absolutely restricted to
> Java 7. However, we have an application that connects to NetSuite, and
> about a week ago, NetSuite stopped allowing access to any of the
> ciphersuites we support out of the box.
>
> The ones we need to support are:
>
>   * ECDHE-RSA-AES128-GCM-SHA256
>   * ECDHE-RSA-AES256-GCM-SHA384
>   * AES128-GCM-SHA256
>   * AES256-GCM-SHA384
>
> None of which are available in Java 7.

BCJSSE supports the first two; the last 2 are TLS 1.3 ciphers which we
don't support yet (TLS 1.3 that is). BCJSSE and all its implemented
ciphersuites support Java versions back to Java 5.


> I copied the latest BCprov and BCtls jars into my jre/lib/ext, updated
> the java.security to list
> org.bouncycastle.jce.provider.BouncyCastleProvider and
> org.bouncycastle.jsse.provider.BouncyCastleJsseProvider as my first and
> second providers, and loaded the unlimited strength crypto policy jars.
> I then added the following arguments when I launch the application:
>
> -Dhttps.protocols=TLSv1.2
> -Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

So these are intended to configure HttpsURLConnection? BCJSSE should be
fine with those settings, but note that BCJSSE itself is not the code
that processes those properties.


> But I get an “unsupported cipher” exception.

Please provide the stack trace of this exception.

I would guess that the HTTPS code isn't actually selecting BCJSSE for
some reason. I would suggest debugging into HttpsURLConnection to find
out how it's setting up an SSLContext and whether (or why not) it's
finding BCJSSE.


> So now I’m wondering if BC will actually provide ciphers it knows about
> if the underlying JRE doesn’t support them. On the other hand, if it is
> possible, I would appreciate some advice.

Yes, all BCJSSE ciphersuites are implemented internally and do not rely
on the underlying JRE. Available ciphersuites are in theory constrained
by the cryptographic primitives available in your configured providers,
but the BC provider supplies all of them in any case.

Regards,
Pete Dettman

Reply | Threaded
Open this post in threaded view
|

RE: Does BC actually provide cipher suites unavailable in Java 7?

DiBaggio, Michael
Thanks to all who replied with suggestions. We were able to get this working, although it required a code change to explicitly pass in the BC JSSEProvider to the SSLContext.

Mike

Michael 
DiBaggio
Cleo  |  
Sr Software Engineer II
  
 
Email: [hidden email]
  |  
Web: www.cleo.com
  
  
Join us for Cleo Connect 2019, October 7-10 in Orlando!  Register today!
 
 
-----Original Message-----
From: Peter Dettman <[hidden email]>
Sent: Monday, July 1, 2019 11:16 AM
To: [hidden email]
Subject: Re: [dev-crypto] Does BC actually provide cipher suites unavailable in Java 7?

Hi Michael,

Responses inline:

On 1/7/19 9:14 pm, DiBaggio, Michael wrote:

> Hi everyone. I haven’t pestered this list with my questions for
> several years, but I’m in a bind again.
>
> I am supporting a product that, for now, is absolutely restricted to
> Java 7. However, we have an application that connects to NetSuite, and
> about a week ago, NetSuite stopped allowing access to any of the
> ciphersuites we support out of the box.
>
> The ones we need to support are:
>
> * ECDHE-RSA-AES128-GCM-SHA256
> * ECDHE-RSA-AES256-GCM-SHA384
> * AES128-GCM-SHA256
> * AES256-GCM-SHA384
>
> None of which are available in Java 7.

BCJSSE supports the first two; the last 2 are TLS 1.3 ciphers which we don't support yet (TLS 1.3 that is). BCJSSE and all its implemented ciphersuites support Java versions back to Java 5.


> I copied the latest BCprov and BCtls jars into my jre/lib/ext, updated
> the java.security to list
> org.bouncycastle.jce.provider.BouncyCastleProvider and
> org.bouncycastle.jsse.provider.BouncyCastleJsseProvider as my first
> and second providers, and loaded the unlimited strength crypto policy jars.
> I then added the following arguments when I launch the application:
>
> -Dhttps.protocols=TLSv1.2
> -Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

So these are intended to configure HttpsURLConnection? BCJSSE should be fine with those settings, but note that BCJSSE itself is not the code that processes those properties.


> But I get an “unsupported cipher” exception.

Please provide the stack trace of this exception.

I would guess that the HTTPS code isn't actually selecting BCJSSE for some reason. I would suggest debugging into HttpsURLConnection to find out how it's setting up an SSLContext and whether (or why not) it's finding BCJSSE.


> So now I’m wondering if BC will actually provide ciphers it knows
> about if the underlying JRE doesn’t support them. On the other hand,
> if it is possible, I would appreciate some advice.

Yes, all BCJSSE ciphersuites are implemented internally and do not rely on the underlying JRE. Available ciphersuites are in theory constrained by the cryptographic primitives available in your configured providers, but the BC provider supplies all of them in any case.

Regards,
Pete Dettman