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-...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
