You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2016/09/19 20:20:44 UTC

Re: [OT] Getting DH parameters from an SSLSocket

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

On 8/31/16 12:45 PM, Christopher Schultz wrote:
> All,
> 
> This isn't Tomcat-related, but many folks on this list have this
> kind of experience, so I'm asking in case anyone knows.
> 
> I'd like to make an HTTPS connection to a server and, if I'm using 
> non-ephemeral DH key exchange, I'd like to know what the
> parameters are for that connection. Actually, I don't really care
> if it's ephemeral or not.
> 
> What I'm looking for is the ability to make a connection and then
> warn if the connection is using "weak" DH parameters. Is that
> something I can check at connection-time? Or is the set of DH
> parameters (or, more specifically, the *length* of those
> parameters, in bits) defined by the cipher suite itself?
> 
> For example, the Qualys community thread has an illustration of
> the cipher suites that SSLLabs considers "weak" (well, everyone
> considers them weak... they just have a public tool which complains
> about them): https://community.qualys.com/thread/14821
> 
> They specifically mention e.g. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 
> which is cipher suite 0x9f and mention the DH parameters. Are
> those parameters' parameters baked-into the cipher suite (meaning
> they are *always* 1024-bit) or is this a configuration of the
> server that makes those cipher suites weak due to the specific DH
> parameter choice?
> 
> In either case, I'd like to be able to sniff that information from
> the connection if at all possible. Does anyone know if this can be
> done, and how?
> 
> Thanks, -chris

It seems that this isn't possible.

Does anyone on the list have the karma required to file an enhancement
request for the Java API? Or does everything need to be a darned JSR?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX4EicAAoJEBzwKT+lPKRYpjQP/1kQhh58iMXp8vTNnbiN+YYg
fICg1Rdol4jCko5BGswNOIbelLAJEb/gt3h+dwE2bKtpyYEk7iRG1/r9UDALxdbk
RX+H3Vmvy/eE7WPoWIJoLqcHbABtzqq+Hbp4F5YKCUYO9deGNt2OSaZtgAA0u5xd
uvr2gWLEA+AH2bDg5aqe4yrg3laRQqqpshCCKpEl/uOCxvFizstvSH61jgu7miMx
CdoHaJXIEJ+Qvgr/+4NXT+DaxiOQDPNJ/hf9rEpO1N5COeIP66N41sUNBI4JD1oW
U1N3h5Hk+6THgIH8n9B9ZXfSHLXNO07+CalEmUKL5NDZJslf/rYln7/uHSbagGaN
utPrMJoFAXuWpW3Q8ObAWtEEat2XjQFcYJfSbFMyEBLR5xmhxYshpnaZh/lMWOQc
4fidk/XzrSw0d646dnVRdlOY7mzRBwucD7Acv0FkQ+gnjRzLKBCmxeXBOKXbsS9H
D6l09H9elMXyOo5lyIhC7x1hANx/MEb0sh/wCmduOVdN4LdepKoUWwCUDvIZwbLf
LnifL+hBS5k5hWfQ5MA/TH6yPZwg/3k9yxMbxAz13fCAIQAy3O2o9GAzYsJJJ9Cy
PQGgkAI7Qr/KfnO1RG4VCn/KuWrSc8ZLg3kEARZjvFb+dloB6R5v09LhlNheTdWO
v0VmwdAW6omgsmqj/VH/
=YtxI
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] Getting DH parameters from an SSLSocket

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 9/29/16 5:38 AM, Mark Thomas wrote:
> On 28/09/2016 22:14, Christopher Schultz wrote:
>> Mark,
>> 
>> On 9/19/16 4:32 PM, Mark Thomas wrote:
>>> On 19/09/2016 21:20, Christopher Schultz wrote:
>>>> All,
>>>> 
>>>> On 8/31/16 12:45 PM, Christopher Schultz wrote:
>>>>> All,
>>>> 
>>>>> This isn't Tomcat-related, but many folks on this list
>>>>> have this kind of experience, so I'm asking in case anyone
>>>>> knows.
>>>> 
>>>>> I'd like to make an HTTPS connection to a server and, if
>>>>> I'm using non-ephemeral DH key exchange, I'd like to know
>>>>> what the parameters are for that connection. Actually, I
>>>>> don't really care if it's ephemeral or not.
>>>> 
>>>>> What I'm looking for is the ability to make a connection
>>>>> and then warn if the connection is using "weak" DH
>>>>> parameters. Is that something I can check at
>>>>> connection-time? Or is the set of DH parameters (or, more
>>>>> specifically, the *length* of those parameters, in bits)
>>>>> defined by the cipher suite itself?
>>>> 
>>>>> For example, the Qualys community thread has an
>>>>> illustration of the cipher suites that SSLLabs considers
>>>>> "weak" (well, everyone considers them weak... they just
>>>>> have a public tool which complains about them): 
>>>>> https://community.qualys.com/thread/14821
>>>> 
>>>>> They specifically mention e.g. 
>>>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 which is cipher suite
>>>>> 0x9f and mention the DH parameters. Are those parameters'
>>>>> parameters baked-into the cipher suite (meaning they are
>>>>> *always* 1024-bit) or is this a configuration of the server
>>>>> that makes those cipher suites weak due to the specific DH
>>>>> parameter choice?
>>>> 
>>>>> In either case, I'd like to be able to sniff that
>>>>> information from the connection if at all possible. Does
>>>>> anyone know if this can be done, and how?
>>>> 
>>>>> Thanks, -chris
>>>> 
>>>> It seems that this isn't possible.
>>>> 
>>>> Does anyone on the list have the karma required to file an 
>>>> enhancement request for the Java API? Or does everything need
>>>> to be a darned JSR?
>> 
>>> I recommend starting with the security-dev@openjdk.java.net
>>> mailing list.
>> 
>>> As far as I know, the process is to raise a bug/enhancement 
>>> request against Java. From my own experience with the memory
>>> leak bugs, it helps a lot if an OpenJDK committer has already
>>> agreed to try and do something about it.
>> 
>> So... crickets so far.
>> 
>> Any suggestions?
> 
> Open an enhancement request and the next time Rory posts to the dev
> list about Java 9 respond with a request to look at your
> enhancement request.
> 
> The more you can tie it back to something that Tomcat needs to
> improve security, the greater the chances of something happening.

Okay.

> That is how I got the memory leak stuff fixed. The advantage I had
> was they were all clear bugs and I had simple tests cases (most of
> the time) to demonstrate them.

Yeah, this is clearly an enhancement request. So, maybe less incentive.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX7UbWAAoJEBzwKT+lPKRYSPMP/1KdZsvY2TqUKqYsu0NSebOF
4jaZVdtG/09JUBjS74qVtujqSS2Kn+wxxqljzZJYL5/sekiXJBu4kjGNwFy1azsM
VkpH1es8x/xGunfUYWDSxYDmofHjaOhPRXm0zNN42ZFb/b2ssa5x5I0IB+xBwuuS
PM/wLcbkUmm/RoabVEUO6Eb7SABKIOCokd5SGNDOY8bPb6xeFrjRDKv5U+6U9cIM
XEXVcOY5UvIwBTxa9mCxOB8uHIC3TiEhVecxToFRD5WK7FJ9BfDpBqLBKYdNK+fF
8500tYH8iWYLO1MmBKS3xsppUIiDu2a1xF7TXTQR41nM6NMeNF6TSBQQoUp0N+bU
F6NNKUHRZMNkv6C1XX7t8gFGg/xP1hYw0IvNkkZjKakptnW84bm1P0VY6D+ZI0TS
HOGpkg8jP7oNrsQEX+IK3HjEYRAHT+j0HR8u6q0Zmal3bkqJ9cjXsYMLHUOEgZAB
BFnawEHsvb87mU3E1uK58F3zzBvnyLq1eU4q9gq1BBQ2vZpufIuYnH2u9l3rWQda
ldG5pjZ/zcHkokO8O0OPo8Eu3MOsG4reSHHIITnLH1AlyaMMyOBCkqpnBZttTIMm
gV3QVI5bjpQ3RNhS0nKZkZycmIBvCgbreMo5zpVZsbe7leHh4SPwSU5ccJiL1YOd
8/83xNVMFvBPx4eX3UWZ
=Z14m
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] Getting DH parameters from an SSLSocket

Posted by Mark Thomas <ma...@apache.org>.
On 28/09/2016 22:14, Christopher Schultz wrote:
> Mark,
> 
> On 9/19/16 4:32 PM, Mark Thomas wrote:
>> On 19/09/2016 21:20, Christopher Schultz wrote:
>>> All,
>>>
>>> On 8/31/16 12:45 PM, Christopher Schultz wrote:
>>>> All,
>>>
>>>> This isn't Tomcat-related, but many folks on this list have
>>>> this kind of experience, so I'm asking in case anyone knows.
>>>
>>>> I'd like to make an HTTPS connection to a server and, if I'm
>>>> using non-ephemeral DH key exchange, I'd like to know what the 
>>>> parameters are for that connection. Actually, I don't really
>>>> care if it's ephemeral or not.
>>>
>>>> What I'm looking for is the ability to make a connection and
>>>> then warn if the connection is using "weak" DH parameters. Is
>>>> that something I can check at connection-time? Or is the set of
>>>> DH parameters (or, more specifically, the *length* of those 
>>>> parameters, in bits) defined by the cipher suite itself?
>>>
>>>> For example, the Qualys community thread has an illustration
>>>> of the cipher suites that SSLLabs considers "weak" (well,
>>>> everyone considers them weak... they just have a public tool
>>>> which complains about them):
>>>> https://community.qualys.com/thread/14821
>>>
>>>> They specifically mention e.g.
>>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 which is cipher suite 0x9f
>>>> and mention the DH parameters. Are those parameters' parameters
>>>> baked-into the cipher suite (meaning they are *always*
>>>> 1024-bit) or is this a configuration of the server that makes
>>>> those cipher suites weak due to the specific DH parameter
>>>> choice?
>>>
>>>> In either case, I'd like to be able to sniff that information
>>>> from the connection if at all possible. Does anyone know if
>>>> this can be done, and how?
>>>
>>>> Thanks, -chris
>>>
>>> It seems that this isn't possible.
>>>
>>> Does anyone on the list have the karma required to file an
>>> enhancement request for the Java API? Or does everything need to
>>> be a darned JSR?
> 
>> I recommend starting with the security-dev@openjdk.java.net mailing
>> list.
> 
>> As far as I know, the process is to raise a bug/enhancement
>> request against Java. From my own experience with the memory leak
>> bugs, it helps a lot if an OpenJDK committer has already agreed to
>> try and do something about it.
> 
> So... crickets so far.
> 
> Any suggestions?

Open an enhancement request and the next time Rory posts to the dev list
about Java 9 respond with a request to look at your enhancement request.

The more you can tie it back to something that Tomcat needs to improve
security, the greater the chances of something happening.

That is how I got the memory leak stuff fixed. The advantage I had was
they were all clear bugs and I had simple tests cases (most of the time)
to demonstrate them.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] Getting DH parameters from an SSLSocket

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 9/19/16 4:32 PM, Mark Thomas wrote:
> On 19/09/2016 21:20, Christopher Schultz wrote:
>> All,
>> 
>> On 8/31/16 12:45 PM, Christopher Schultz wrote:
>>> All,
>> 
>>> This isn't Tomcat-related, but many folks on this list have
>>> this kind of experience, so I'm asking in case anyone knows.
>> 
>>> I'd like to make an HTTPS connection to a server and, if I'm
>>> using non-ephemeral DH key exchange, I'd like to know what the 
>>> parameters are for that connection. Actually, I don't really
>>> care if it's ephemeral or not.
>> 
>>> What I'm looking for is the ability to make a connection and
>>> then warn if the connection is using "weak" DH parameters. Is
>>> that something I can check at connection-time? Or is the set of
>>> DH parameters (or, more specifically, the *length* of those 
>>> parameters, in bits) defined by the cipher suite itself?
>> 
>>> For example, the Qualys community thread has an illustration
>>> of the cipher suites that SSLLabs considers "weak" (well,
>>> everyone considers them weak... they just have a public tool
>>> which complains about them):
>>> https://community.qualys.com/thread/14821
>> 
>>> They specifically mention e.g.
>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 which is cipher suite 0x9f
>>> and mention the DH parameters. Are those parameters' parameters
>>> baked-into the cipher suite (meaning they are *always*
>>> 1024-bit) or is this a configuration of the server that makes
>>> those cipher suites weak due to the specific DH parameter
>>> choice?
>> 
>>> In either case, I'd like to be able to sniff that information
>>> from the connection if at all possible. Does anyone know if
>>> this can be done, and how?
>> 
>>> Thanks, -chris
>> 
>> It seems that this isn't possible.
>> 
>> Does anyone on the list have the karma required to file an
>> enhancement request for the Java API? Or does everything need to
>> be a darned JSR?
> 
> I recommend starting with the security-dev@openjdk.java.net mailing
> list.
> 
> As far as I know, the process is to raise a bug/enhancement
> request against Java. From my own experience with the memory leak
> bugs, it helps a lot if an OpenJDK committer has already agreed to
> try and do something about it.

So... crickets so far.

Any suggestions?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX7DLSAAoJEBzwKT+lPKRY/bUQAMFXZp7Ci0u7SEwTsw5dCro5
qs7ejnvJJY5FzRNt4vdBDmrWF1BQUcUnF+bI47+YSyv4KAwvwvBfVrYbd1E+103y
RgFum3RTNYPyicO8D1C/4u0M5GtmEp3Umrf+EW5JPyYzbiE7PP4mMzfmjuw2zL+S
Rnt426FCurTjdsLJR+bcSYbWEpIm2qkmVEVRvExBG9Vx9e8jYBy+nr7zRh/tEnWb
NnENErIpyls359X5vsyLbM4CvZI3gOkflKdWf17j0P8iAWUm0LGmsRV5Gcn+KDIj
ZLsld8Vk825eBFVskdEFAO7GXdoBw+ZVTFCIXbI5Cwh4qArNMHRix9FUCTj9pNFH
T0Vqqv35Xo3YqzCocozYaqQWV1KpPj8j01SLcHibTDbeyvMWvwsJRqyRG94a0y+x
ftWVNf2LJhd0vr6p6i61Xa3MN8cxD0vlFbUB2ec5DJ0tJ7QFiqF0pMvRXZpzXEf1
zOH6F3UAlx5S/3TPYlWpO/aAJeMQBUh/c8f3wgvj50nn0C/5U00b/clF0+5j6/SY
fpvxjX4qxFjRBK3BomO+Oplgt/ORdrb5HiwNwYcLcgjLs5Cw/fhFjINzm6ZBPNSr
xmuAPOoWuIFFaLQ8iWbkiV3rv3slmXTu/uvDz2etTmK1qzB/4ccHOGAsXGyniC9D
amdC4VCgfIZVYJyurBqb
=jpPl
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] Getting DH parameters from an SSLSocket

Posted by Mark Thomas <ma...@apache.org>.
On 19/09/2016 21:20, Christopher Schultz wrote:
> All,
> 
> On 8/31/16 12:45 PM, Christopher Schultz wrote:
>> All,
> 
>> This isn't Tomcat-related, but many folks on this list have this
>> kind of experience, so I'm asking in case anyone knows.
> 
>> I'd like to make an HTTPS connection to a server and, if I'm using 
>> non-ephemeral DH key exchange, I'd like to know what the
>> parameters are for that connection. Actually, I don't really care
>> if it's ephemeral or not.
> 
>> What I'm looking for is the ability to make a connection and then
>> warn if the connection is using "weak" DH parameters. Is that
>> something I can check at connection-time? Or is the set of DH
>> parameters (or, more specifically, the *length* of those
>> parameters, in bits) defined by the cipher suite itself?
> 
>> For example, the Qualys community thread has an illustration of
>> the cipher suites that SSLLabs considers "weak" (well, everyone
>> considers them weak... they just have a public tool which complains
>> about them): https://community.qualys.com/thread/14821
> 
>> They specifically mention e.g. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 
>> which is cipher suite 0x9f and mention the DH parameters. Are
>> those parameters' parameters baked-into the cipher suite (meaning
>> they are *always* 1024-bit) or is this a configuration of the
>> server that makes those cipher suites weak due to the specific DH
>> parameter choice?
> 
>> In either case, I'd like to be able to sniff that information from
>> the connection if at all possible. Does anyone know if this can be
>> done, and how?
> 
>> Thanks, -chris
> 
> It seems that this isn't possible.
> 
> Does anyone on the list have the karma required to file an enhancement
> request for the Java API? Or does everything need to be a darned JSR?

I recommend starting with the security-dev@openjdk.java.net mailing list.

As far as I know, the process is to raise a bug/enhancement request
against Java. From my own experience with the memory leak bugs, it helps
a lot if an OpenJDK committer has already agreed to try and do something
about it.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org