Hi,
happy new year and it starts as last year ended: I'm answering to my own mails ;-)
German Usenet once called it (translated) "doing the Ingrid".
Fist of all: My original problem really seemed to be a Java version related
thing. After updating to the most current version of Java 1.8 that particular
test succeeded on Linux as well (and up to Java 15). But there are other (platform
independent problems).
Am 29.12.2020 um 13:27 schrieb Lothar Kimmeringer:
>
> Am 29.12.2020 um 11:36 schrieb Lothar Kimmeringer:
>>> is it using the same underlying TLS stack or is it platform-specific?
>>
>> No platform dependency here.
>> Up until yesterday I was using JSSE but changed it to BCJSSE.
>
> Have to take that back, by accident the test still used SunJSSE
> as provider for the server side of the test. When changing that
> to BCJSSE the test fails again because no session IDs are returned:
>
> 13:19:42 [MESSAGE] SYSTEM:FTP:FTPDAEMON SecureFtpDaemon@0.0.0.0:41029 TLS connection established with protocol TLSv1.2 and cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> 13:19:42 [MESSAGE] SYSTEM:FTP:FTPDAEMON SecureFtpDaemon@0.0.0.0:41029 control channel ssl session id:
> 13:19:42 [MESSAGE] SYSTEM:FTP:FTPDAEMON SecureFtpDaemon@0.0.0.0:41029 control channel creation time: 1609244382940
> 13:19:42 [MESSAGE] SYSTEM:FTP:FTPDAEMON SecureFtpDaemon@0.0.0.0:41029 data channel ssl session id :
> 13:19:42 [MESSAGE] SYSTEM:FTP:FTPDAEMON SecureFtpDaemon@0.0.0.0:41029 data channel creation time: 1609244382982
I found the reason for that as well. BC's server side has session resumption diabled
by default, so by switching the provider default-behaviors are changing. Setting
the system property org.bouncycastle.jsse.server.enableSessionResumption to true,
that test case also succeeds.
But still I'm ending up with problems if the server uses BC-sockets and a
client using SunJSSE tries to connect to it:
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1592985036 bytes = { 67, 169, ... }
Session ID: {}
Cipher Suites: [TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, ..., TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
13:15:08 [MESSAGE] SYSTEM:FTP:FTPDAEMON SecureFtpDaemon@0.0.0.0:18610 received ftp-connection from 127.0.0.1, concurrent connections=0
Extension extended_master_secret
***
main, WRITE: TLSv1.2 Handshake, length = 193
Jan 04, 2021 1:15:08 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSystemProperty
INFORMATION: Found boolean system property [org.bouncycastle.jsse.server.enableSessionResumption]: true
Jan 04, 2021 1:15:08 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyAlertRaised
INFORMATION: Server raised fatal(2) handshake_failure(40) alert: Failed to read record
org.bouncycastle.tls.TlsFatalAlert: handshake_failure(40)
at org.bouncycastle.tls.AbstractTlsServer.getSelectedCipherSuite(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsServer.getSelectedCipherSuite(Unknown Source)
at org.bouncycastle.tls.TlsServerProtocol.generateServerHello(Unknown Source)
at org.bouncycastle.tls.TlsServerProtocol.handleHandshakeMessage(Unknown Source)
So the BC-based server doesn't accept the SunJSSE's ClientHello. To rule out
side effects of the server application this part is running in (which isn't much
in the context of a JUnit-Testcase but still), I've created a TestCase that only
contains the stuff to do TLS connections and resumptions. It's attached to this
mail and also fails if a SunJSSE provider based SSL-socket is trying to connect
to a BCJSSE based server socket.
So I ses three issues here (both I can create on GitHub but I like to get some
feedback first if this doesn't end up as as PEBKAC):
- There seem to be a dependency on the update-level of Java 1.8 somewhere.
The minimum update level should be mentioned somewhere (if it's already,
I haven't found it) or - even better - checked by the provider and if
the requirement isn't met, an exception should be raised.
- When using the JSSE-API, changing the provider from SunJSSE to BCJSSE
changes the server's behavior on TLS session resumption. With SunJSSE
session resumption is enabled, with BCJSSE it's disabled. IMHO, behaviors
shouldn't change on that level
- A SunJSSE SSLSocket on the client side and a BCJSSE SSLSocket on the server
side are incompatible with TLSv1.2 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
(not that I've searched for this combination, it's the one being agreed on
during my tests). I haven't checked other ciphers and switching to one of
them as a workaround wouldn't help because in real life I have no control
over the client.
BTW: I've created the test to make it quite easy to test different combinations
of TLS protocol, used providers and ciphers. If you see it as useful for the
test suite in BouncyCastle, feel free to add it there (it's using Java 8 features,
though).
Thanks and cheers, Lothar