Archive

Here's a real-world example of what I've just been going through with
regard to Java and DHE:

https://github.com/jruby/jruby/issues/2872

Note the ticket is about the general problem, and in the course of it there
have been multiple manifestations of the problem.

On Wed, Jun 3, 2015 at 12:00 AM, Tony Arcieri <bascule@gmail.com> wrote:

> So this is the exact problem I've been talking about.
>
> After this draft is actually implemented in all TLS servers everywhere,
> server operators can add Java-specific errata to their configuration to
> work around the fundamental problem that DHE is breaking Java TLS
> handshakes.
>
> Or you can just add the Java property I cited above. Which is total
> oddball errata. Nobody should have to worry about jdk.tls.disabledAlgorithms="DHE
> keySize > 2048"
>
> This is just adding to the "headache" of maintaining a modern TLS stack.
>
> I'll freely admit I just made mistakes trying to diagnose this problem but
> as a practitioner I seriously don't care about supporting these things and
> want them to just go away and for TLS handshakes to just work and not
> spontaneously break because of misconfigurations.
>
> I don't see how adding more complexity fixes the problem.
>
> I just want DHE to diediedie.
>
> Perhaps someone can explain how keeping DHE around is actually beneficial
> in any way whatsover? Right now it's just giving me a headache and making
> me angry.
>
>
> On Tue, Jun 2, 2015 at 11:54 PM, Yuhong Bao <yuhongbao_386@hotmail.com>
> wrote:
>
>> The idea is that the server can send a different weaker DHE key in the
>> ServerKeyExchange, or not use DHE suites at all.
>>
>> ________________________________
>> > From: bascule@gmail.com
>> > Date: Tue, 2 Jun 2015 23:52:36 -0700
>> > Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt
>> > To: yuhongbao_386@hotmail.com
>> > CC: geoffk@geoffk.org; tls@ietf.org
>> >
>> > Yes sorry I meant ClientKeyExchange...
>> >
>> > But can you explain to me how this solves the problem for legacy
>> clients?
>> >
>> > On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao
>> > <yuhongbao_386@hotmail.com<mailto:yuhongbao_386@hotmail.com>> wrote:
>> > The client don't receive the ServerKeyExchange message containing the
>> > DHE key at all until after they sent the ClientHello.
>> >
>> > ________________________________
>> >> From: bascule@gmail.com<mailto:bascule@gmail.com>
>> >> Date: Tue, 2 Jun 2015 23:35:46 -0700
>> >> To: geoffk@geoffk.org<mailto:geoffk@geoffk.org>
>> >> CC: tls@ietf.org<mailto:tls@ietf.org>
>> >> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt
>> >>
>> >> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating
>> >>
>> > <geoffk@geoffk.org<mailto:geoffk@geoffk.org><mailto:geoffk@geoffk.org
>> <mailto:geoffk@geoffk.org>>>
>> > wrote:
>> >> It's covered in section 4:
>> >>
>> >> If at least one FFDHE ciphersuite is present in the client
>> >> ciphersuite list, and the Supported Groups extension is either absent
>> >> from the ClientHello
>> >>
>> >> Unless I'm mistaken, unless you configure the
>> >> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize
>> >>> 2048"), Java clients are aborting *before* they send the ClientHello.
>> >> Please let me know if you're seeing otherwise. I could be mistaken and
>> >> perhaps there's a server-side workaround for this that isn't "disable
>> >> all DHE ciphersuites". But this is what I've personally observed and
>> >> have been advising people about.
>> >>
>> >> I'm not saying it can't be fixed with additional
>> >> configuration/errata/etc, I'm arguing that it's *breaking clients in
>> >> the field right now*
>> >>
>> >> tl;dr: I am seeing *widespread TLS breakages* because of this resulting
>> >> in *huge outages* for Java clients
>> >>
>> >> --
>> >> Tony Arcieri
>> >>
>> >> _______________________________________________ TLS mailing list
>> >> TLS@ietf.org<mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls
>> >
>> >
>> >
>> >
>> > --
>> > Tony Arcieri
>>
>
>
>
>
> --
> Tony Arcieri
>

-- 
Tony Arcieri