svn commit: r303716 - head/crypto/openssh

[Slawa Olhovchenkov]

On Sun, Aug 07, 2016 at 09:34:51PM +0300, Andrey Chernov wrote:

> On 07.08.2016 21:23, Slawa Olhovchenkov wrote:
> > On Sun, Aug 07, 2016 at 09:06:37PM +0300, Andrey Chernov wrote:
> > 
> >> On 07.08.2016 20:43, Andrey Chernov wrote:
> >>> On 07.08.2016 20:37, Slawa Olhovchenkov wrote:
> >>>> On Sun, Aug 07, 2016 at 08:34:55PM +0300, Andrey Chernov wrote:
> >>>>
> >>>>> On 07.08.2016 20:31, Andrey Chernov wrote:
> >>>>>> On 07.08.2016 19:14, Bruce Simpson wrote:
> >>>>>>> On 07/08/16 15:40, Warner Losh wrote:
> >>>>>>>> That’s a cop-out answer. We, as a project, need to articulate to our
> >>>>>>>> users, whom we care about, why this rather obnoxious hit to usability
> >>>>>>>> was taken. The answer must be more complete than “We just disabled
> >>>>>>>> it because upstream disabled it for reasons we’re too lazy to explain
> >>>>>>>> or document how to work around"
> >>>>>>>
> >>>>>>> Alcatel-Lucent OmniSwitch 6800 login broken (pfSense 2.3.2 which
> >>>>>>> accepted the upstream change, workaround no-go)
> >>>>>>>
> >>>>>>> [2.3.2-RELEASE][root at gw.lab]/root: ssh -l admin
> >>>>>>> -oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.XXX
> >>>>>>> Fssh_ssh_dispatch_run_fatal: Connection to 192.168.1.XXX port 22: DH GEX
> >>>>>>> group out of range
> >>>>>>>
> >>>>>>
> >>>>>> DH prime size must be at least 2048, openssh now refuse lower values.
> >>>>>> Commonly used DH size 1024 can be easily broken. See https://weakdh.org
> >>>>>>
> >>>>> diffie-hellman-group1-sha1 use DH 1024 and insecure sha1 both.
> >>>>
> >>>> IMHO, this is wrong choise: totaly lost of control now vs teoretical
> >>>> compromise of control in the future.
> >>>
> >>> Please note that it was not my choice and I can't answer what to do with
> >>> non-upgradeable hardware question, address it to the author. I just tell
> >>> you _why_ it happens.
> >>>
> >>
> >> BTW, compromise is practical enough. From https://weakdh.org/ "A close
> >> reading of published NSA leaks shows that the agency's attacks on VPNs
> >> are consistent with having achieved such a break."
> > 
> > For this compromise need
> > 
> > 1) NSA interesed to me
> 
> This particular condition is not necessary, they can decrypt all traffic
> with weak DH primes passed through main channels in USA and perhaps
> partially in Europe (depends on mutual agreement), then find interesting
> keywords to spy more closely afterwards.

My interraction with weak devices don't cross EU/USA borders.
I am assume Bruce's interraction with weak devices don't cross server
room.

Yes, I am know about 'security in depth'.
But PCI-DSS don't be need at any places.

> > 2) NSA must be able to access to weak device for traffic
> > intercept
> > 
> > This is imposible at this time.
> > 
> > Also, if NSA can be able to intercept such traffic weak crypto will be
> > last resort of my trouble.
> 
> About the rest, I am not the person to argue with. Why you still not

I am not convince you. 
I am also just talk my opinion (as you).

> send your opinion to the author?
> 

I am not sure about suitable response from autor.
May be project [FreeBSD] choise some compromise.

Last time I am have only two devices with weak crypto.
One device can be accept only DES.
Other accept only rsa/dss (if not hanged).
I am able to create ssh client with support this weak ciphers for
access to this devices. I am will be sad about causeless enforcing
strong crypto.