Re: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



On Tue, 2014-10-21 at 21:15 +0000, Christian Weisgerber wrote: 
> > Why is there never a step, in which the server S somehow verifies that e
> > actually comes from C (i.e. authenticating C)?
> That's just the overall protocol design.  There is no client
> authentication at this stage, only server authentication.
> Client authentication happens in the SSH authentication protocol
> https://tools.ietf.org/html/rfc4252
> Typical client authentication relies on the user's public key or
> password.  What would be gained by authenticating the client's host?

I rather wondered here, how one defends against Mallory at this stage of
the DH handshake... but it's probably enough to check at either client
or server side that e respectively f is from the authenticated Alice or
Bob, in order to prevent MitM, right?
Cause already if one side notices the attack, the handshake won't
complete.


> > Wouldn't it be nice to have an option to set min/pref/max?
> No.
Well why not?
There what's the current value for min/max?
#define DH_GRP_MIN      1024
#define DH_GRP_MAX      8192

Right?
When you go for the ECRYPT II estimations, 1024 is only enough for the
very short term.
Of course an "evil" server can just always publish your data, stronger
DH params or not... but I think the question is mainly about avoiding
"accidental" weak defaults.

And 8192 is at least to small for the forseeable future. Now I
understand that there is this limit from the RFC, but AFAICS this is
only a suggested limit and not a hard one, isn't it?


> What is your attack scenario here?  If the server can't be trusted,
> your session isn't protected.  That is trivial.
See above: it's all about simple checks against weak defaults.
If this wouldn't make sense, then one could also set min=0 and simply
blindly trust the server.

> Hey, the server might accidentally use a weak random number generator.
> That isn't even hypothetical.
Sure, but that's nothing we could check.

Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux