[prev in list] [next in list] [prev in thread] [next in thread]
List: bouncycastle-crypto-dev
Subject: RE: [dev-crypto] jTDS and BCJSSE
From: "Eckenfels. Bernd" <B.Eckenfels () seeburger ! de>
Date: 2017-11-11 1:59:50
Message-ID: ED12D06EC205E3458FC3E23CD84D4ED50202AC7694 () dedcexch02 ! seeburger ! de
[Download RAW message or body]
Hello,
When request method is used jTDS will wrap the raw Socket to the SQL Server with a \
SSLSocket for the actual authentication. However if the server does not support SSL \
it will close and remove it.
This can now mean two things, first of all it could mean that the other TLS providers \
manage to establish SSL and do not disableEncryption() or it means the closing of the \
other providers does not close the underlying Socket. I think however the first is \
more likely, as it seems the jTDS is incorrectly using autoClose=true, which should \
make all TLS providers to corrupt the existing Socket.
Especially in a FIPS environment, I,would use ssl=require or ssl=authenticate. There \
is no much sense in using approved crypto if you turn it off.
With that setting there should be a clear exception why the handshake fails. The \
second half of the mail demonstrates however that there are no clear exceptions, \
however at least we know why „request“ tried to rollback the wrapping.
Gruss
Bernd
-
http://www.seeburger.com
________________________________________
From: Peter Dettman [peter.dettman@bouncycastle.org]
Sent: Friday, November 10, 2017 18:41
To: dev-crypto@bouncycastle.org; bradford.root@gmail.com
Subject: Re: [dev-crypto] jTDS and BCJSSE
Hi Brad,
Nothing immediately leaps out at me, but I am not familiar with jTDS and
rusty on JDBC. A few comments inline below, but we're probably going to
need more details or even a reproducible test-case in order to help.
On 10/11/17 1:45 am, Brad Root wrote:
> Hello,
>
> We’re looking to replace our RSA BSAFE JSSE (FIPS) provider with BCJSSE
> and are running into issues with jTDS connections to SQL Server. Our
> security providers are configured statically as so:
>
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> C:DEFRND[HMACSHA256];ENABLE{ALL};
> security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
> fips:BCFIPS
> security.provider.3=sun.security.provider.Sun
> 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
> security.provider.8=sun.security.mscapi.SunMSCAPI
> security.provider.9=com.sun.crypto.provider.SunJCE
Seems fine. Depending on your client-auth configuration, perhaps
double-check that you are setting this in java.security also:
ssl.KeyManagerFactory.algorithm=PKIX
BCJSSE currently only works with its own KeyManagerFactory ("PKIX").
> First, when the JDBC connection string is configured with ssl=request
> (i.e. jTDS use secure connections to SQL Server if available), we
> observe the following exception:
>
> java.sql.SQLException: I/O Error: Socket is closed
> at net.sourceforge.jtds.jdbc.TdsCore.login(TdsCore.java:657)
> at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:393)
> at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:185)
> at java.sql.DriverManager.getConnection(DriverManager.java:664)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at Main.tryJtds(Main.java:86)
> at Main.main(Main.java:41)
> Caused by: java.net.SocketException: Socket is closed
> at java.net.Socket.getOutputStream(Socket.java:943)
> at
> net.sourceforge.jtds.jdbc.SharedSocket.disableEncryption(SharedSocket.java:343)
> at net.sourceforge.jtds.jdbc.TdsCore.login(TdsCore.java:631)
> ... 6 more
>
> This does not occur with ssl=off or ssl=require, nor does it occur when
> we use the RsaJSSE or SunJSSE JSSE providers. Whether or not the
> provider is in FIPS (approved) mode does not change the behavior.
I don't see any BC code in the stack traces - was it truncated away?
Do I understand that it reliably fails with ssl=request ? It might be
interesting to understand how ssl=request works (or should work). The
stack trace below shows the use of wrapped sockets for TLS, so perhaps
ssl=request is beginning TLS on a socket that has already exchanged data
- or the reverse? I think it's a scenario that hasn't been tested much
for BCJSSE, so a plausible place for a bug. Just guessing though.
Also, could you confirm that the server configuration is consistent
across the ssl=off/request/require tests i.e. the server has ssl enabled
so it should be used for both request/require.
> Second, when we use specify ssl=require, we can establish connections,
> but we intermittently observe SocketExceptions. For example:
>
> Nov 08, 2017 4:54:39 PM org.bouncycastle.jsse.provider.ProvTlsClient
> notifyAlertRaised
> WARNING: Client raised fatal(2) internal_error(80) alert: Failed to
> write record
> java.net.SocketException: Connection reset by peer: socket write error
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
> at
> net.sourceforge.jtds.ssl.TdsTlsOutputStream.write(TdsTlsOutputStream.java:149)
> at java.io.FilterOutputStream.write(FilterOutputStream.java:97)
> at org.bouncycastle.tls.RecordStream.writeRecord(Unknown Source)
> at org.bouncycastle.tls.TlsProtocol.safeWriteRecord(Unknown Source)
> at org.bouncycastle.tls.TlsProtocol.writeApplicationData(Unknown Source)
> at
> org.bouncycastle.jsse.provider.ProvSSLSocketWrap$AppDataOutput.write(Unknown
> Source)
> at java.io.DataOutputStream.write(DataOutputStream.java:107)
> at
> net.sourceforge.jtds.jdbc.SharedSocket.sendNetPacket(SharedSocket.java:685)
> at net.sourceforge.jtds.jdbc.RequestStream.putPacket(RequestStream.java:570)
> at net.sourceforge.jtds.jdbc.RequestStream.flush(RequestStream.java:518)
> at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1091)
> at
> net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:598)
> at
> net.sourceforge.jtds.jdbc.JtdsStatement.executeImpl(JtdsStatement.java:843)
> at net.sourceforge.jtds.jdbc.JtdsStatement.execute(JtdsStatement.java:1316)
> . . .
AFAICT, this is just a straight-forward closed socket post-handshake,
which must fail the TLS connection. Is it possible there was an earlier
exception?
Can you give an idea of how "intermittent" this is, and I assume you are
saying you rarely/never see this with the other JSSE providers (testing
with ssl=require)?
> Any ideas?
- For the sake of completeness, please confirm that you are using the
latest available versions of FIPS and BCJSSE.
- Another user has reported issues with SocketTimeoutException handling,
especially in a scenario with connection pooling, although I don't yet
fully understand the interaction. The stack trace doesn't really hint at
that, but disabling connection pooling (I assume it exists here?) might
be an interesting diagnostic test.
Regards,
Pete Dettman
SEEBURGER AG Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office: Axel Haas, Michael Kleeberg, \
Friedemann Heinz, 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: info@seeburger.de 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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic