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