Re: [TLS] Broken browser behaviour with SCADA TLS

[Hubert Kario <[e-mail]>]

On Thursday, 5 July 2018 04:32:08 CEST Peter Gutmann wrote:
> David Benjamin <[e-mail]>​ writes:
> >The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit
> >minimum. (Chrome enabled far more DHE ciphers than others, so we
> >encountered a lot of this.) 2048-bit was completely hopeless. At the time
> >of removal, 95% of DHE negotiations made by Chrome used a 1024-bit
> >minimum.
> 
> How does Google, rather than the people running the systems being connected
> to, know that 1024-bit DH isn't secure enough for a given environment?  The
> majority of this stuff is running on isolated, private networks or inside
> VPN tunnels for which pretty much anything, including 512-bit keys, are
> fine.

There Is No Such Thing As A Trusted Network

and there wasn't for half a decade at least

If the IPsec is used for p2p security, then the TLS is useless in the first 
place. If there is "last leg" that goes over regular copper or fibre, then TLS 
is providing the security, so 512 big keys are NOT secure

https://cloud.google.com/beyondcorp/
https://blog.cloudpassage.com/2015/10/06/the-end-of-trusted-networks/
and dozens of other articles on the topic

I'll just ignore the fact that no browser has ability to tell if it is 
connecting over such "secure" network or not, let alone making it 
unexploitable for regular Internet connections...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic