[MIRTH-3492] Reevaluate supported SSL protocols and cipher suites Created:
17/Oct/14 Updated: 13/Jan/15 Resolved: 11/Nov/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
Mirth Connect
Administrator, Server
2.2.3, 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.1.0
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
Nick Rupley
Fixed
None
Not Specified
Issue Links:
Relates
relates to MIRTH-3572 Web Service sender no longer loads cl...
relates to MIRTH-3521 Allow the protocols and cipher suites...
3.1.1, 3.2.0
Priority:
Assignee:
Votes:
Security
Nick Rupley
0
Not Specified
Not Specified
Closed
Open
Description
This came about because of the recent POODLE vulnerability, which affects HTTPS traffic
between the client and server.
For easy reference, here's the list of default protocols / cipher suites we decided to use:
Client Protocols:



TLSv1.2
TLSv1.1
TLSv1
Server Protocols:




TLSv1.2
TLSv1.1
TLSv1
SSLv2Hello
Cipher Suites:












































TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA






SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
That is a broad, Java 8 inclusive list. Java 6 and 7 don't even support some of the protocols /
cipher suites listed. However when we actually set them on sockets, we first check the actual
supported list from the JVM, and take the union of the two sets. So for example with Java 6,
only TLSv1 and SSLv2Hello would actually be used.
Comments
Comment by Nick Rupley [ 03/Nov/14 ]
Update: We actually can set those for SMTP/IMAP/POP3, see subsequent comments.
On the server side, we'll be able to do it for Jetty (the MC web server, HTTP Listeners) and HttpServer
(WS Listener). The rub is that while Jetty supports passing in either the included or excluded
protocols/suites, HttpServer and HttpComponents only support passing in the included protocols/suites.
To make this consistent, we'll probably have to change the way we start up the main web server such that
it passes in explicitly included protocols and cipher suites. So that means we'll need to make a list of
everything we want to include, not what we want to exclude.
These would be configurable in mirth.properties:


https.protocols
https.ciphersuites
Comment by Nick Rupley [ 03/Nov/14 ]
After some research, here's the list of protocols and cipher suites I propose:
Protocols:


TLSv1.1
TLSv1.2
Cipher Suites:




TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384













































TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
We don't want to enable the more general TLSv1 (1.0) because it leaves us vulnerable to the BEAST
attack. Compression is already disabled so we don't have to worry about CRIME. And then obviously
SSLv2 and SSLv3 need to be disabled.
As far as cipher suites go, basically anything with RC4 or DES should be disabled due to known attacks
(triple DES is fine). When using block ciphers GCM should be preferred if available, though SunJSSE
doesn't support that out of the box until Java 8. In any case, AES should be preferred over 3DES as its
replacement. Higher key sizes really don't matter that much, but 256 is preferred over 128 anyway. Not
all of the listed cipher suites will actually be available in all environments; depends on the provider used.
The cipher names are Java-specific and look different than they might in OpenSSL, etc. They come from
the actual JSSE specs:
Java 6: http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html
Java 7: http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
Java 8: http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
Comment by Nick Rupley [ 07/Nov/14 ]
Since Java 6 does not support TLSv1.1 or TLSv1.2, we will have to still allow TLSv1 for 3.1.1. However
for 3.2.0 with , that should no longer be necessary.
Comment by Nick Rupley [ 10/Nov/14 ]
The protocols and cipher suites are now configurable in mirth.properties. By default, we've disabled
SSLv3 in light of the POODLE vulnerability, but if necessary (e.g. if a user needs to connect to a legacy
system that doesn't support TLSv1.0 or greater) then the option is there.
This affects the main Mirth Connect server, as well as any connector or plugin that may use SSL
(DICOM/HTTP/WS/etc.). The only exception is SMTP client requests (alerts, SMTP Sender). However
since e-mail is not an inherently secure method of transferring data to begin with, it's not as big of a deal.
Even if security was guaranteed to the immediate endpoint, it may not be guaranteed along each
respective relay on the way to the actual mail server.
Comment by Wayne Huang [ 10/Nov/14 ]
I noticed that Test Connection no longer works with the default settings after these changes from a Java 6
HTTP Sender to a Java 7 HTTP Listener. Downloading the cert also doesn't work.
SSLServerUtil.downloadServerCertificates does not have their protocols and cipher suites set, although it
may be debatable whether they should. I'm somewhat confused as to why the aforementioned scenario
doesn't work. My Java 7 HTTP Listener supports TLSv1 and so does my Java 6 HTTP Sender with the
default settings. I'm pretty sure I saw that they shared cipher suites in common as well.
I'd like to clear up any uncertainties so let's try and figure this out tomorrow. I think that even though the
test connection failed, the message was still able to send correctly after I manually added the cert into the
sender's truststore.
Also, I did try the same thing in 3.1.0 and test connection did work, so it does seem to be related to these
changes.
Comment by Nick Rupley [ 10/Nov/14 ]
If you add SSLv2Hello to your listener server, the Java 6 client should be able to connect just fine.
Obviously if we used the same set on the client in the downloadServerCertificates method it should work
as well. Sounds like we should add SSLv2Hello by default, and also apply the protocols / cipher suites to
SSLServerUtil as well (that was an oversight to begin with).
Reading a bit more, we should probably also add TLS_EMPTY_RENEGOTIATION_INFO_SCSV. It's
not a cipher suite per se, but is included along with the list of cipher suites in the Java SSLSocket. More
information here:
https://ask.wireshark.org/questions/15117/tls_empty_renegotiation_info_scsv-query
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#tlsRenegotiation
http://www.ietf.org/mail-archive/web/tls/current/maillist.html
Comment by Nick Rupley [ 11/Nov/14 ]
Fixed the above. Not only is the SSL Manager now correctly setting the protocols / cipher suites when
testing the connection, but also SSLv2Hello has been added to the list of default protocols.
Just to be clear, this does not mean that SSL 2.0 is supported. JSSE 6+ doesn't even support SSL 2.0 to
begin with. The SSLv2Hello is a sort of psuedo-protocol, wherein the ClientHello uses the SSLv2 format,
but the actual version bytes sent are different, like 0x0303 for TLSv1.2. It's part of the actual TLS 1.2
specifications, though it recommends against using it (not for security reasons, but because it's
deprecated). However since it appears this is still a fairly common thing for clients to do, we should
support it.
Also added the "Signaling Cipher Suite Value" for the reasons outlined in the previous comment.
Comment by Nick Rupley [ 11/Nov/14 ]
Revision 7458: Split up the protocol list in mirth.properties into a client-specific list and server-specific
list. This is because by default, Java enables a different set of protocols on the client side than it does on
the server side.
In Java 7, TLSv1.1, TLSv1.2, and SSLv2Hello were not enabled by default on the client. According to
the JSSE provider specifications, this is because some server don't implement forward-compatibility and
cannot accept the newer formats. The SSLv2Hello protocol is only a pseudo protocol wrapper, but is also
disabled by default because some newer servers choose to no longer accept the old ClientHello format.
In Java 8, TLSv1.1 and TLSv1.2 are enabled by default on the client, but SSLv2Hello is not.
Because of these discrepancies and because we want to allow for workarounds in case users are actually
on older versions of Java, we split up the protocols list so users can override the defaults for the client and
server separately.
Comment by Nick Rupley [ 11/Nov/14 ]
This ability to use custom sets of protocols / cipher suites does not yet apply to the Client object used by
the CLI, manager, or web administrator (those will use the defaults we set in MirthSSLUtil). However
MIRTH-3521 will address that.
Comment by Wayne Huang [ 11/Nov/14 ]
This ability to use custom sets of protocols / cipher suites does not yet apply to the Client
object used by the CLI, manager, or web administrator (those will use the defaults we set
in MirthSSLUtil).
However, SSLv3 has been disabled for those connections as well.
Comment by Nick Rupley [ 11/Nov/14 ]
Revision 7460: Added custom protocols / cipher suites support to e-mail connections as well
(SMTP/IMAP/POP3). This applies to the SMTP Sender, alert e-mails, custom SMTPConnectionFactory
e-mails from JavaScript, and the Email Reader extension.
Comment by Wayne Huang [ 11/Nov/14 ]
Verified the email connector changes.
Generated at Tue Feb 09 08:12:09 PST 2016 using JIRA 6.2.7#6265sha1:91604a8de81892a3e362e0afee505432f29579b0.