The TLS 1.2 Deadline is Looming, Do You Have Your Act Together?:
In the pantheon of security configuration duties for organizations running internet assets, maintaining the latest TLS encryption protocols to keep the cryptographic apparatus at full strength is one of the most fundamental. TLS provides cover for the most sensitive personal and financial information that moves across the internet. As experts in measuring and monitoring third-party risk, RiskRecon and the data scientists from Cyentia Institute recently published a new report that leveraged unique scan data from millions of web servers around the world, via the RiskRecon platform, to see where the rollout of TLS 1.2[*] is going smoothly and where it is meeting resistance.
Together with its precursor SSL, TLS has long been in the crosshairs of both attackers and security researchers who understand that a weak or non-existent deployment of the protocol makes it trivial enough to carry out man-in-the-middle and other attacks against the vulnerable target.
[...] Sectors such as Education (47%), Energy (40%), and Public Administration (37%) have struggled to implement TLS 1.2 protocols. This revelation led us to ask another question – “Are these hosts collecting and transmitting important information using vulnerable protocols?” The RiskRecon portal also determines web host value by examining whether a website collects and transmits important PII or credential information. If we restrict our view to just these high-value hosts, we can zero in on where the lack of TLS 1.2 represents a substantial risk: 1 in 10 organizations transmit private information over flawed protocols.
While our study found that this fundamental protocol lacks attention from some IT Security teams, it does not need any further introduction to those who would look to exploit any vulnerability in web communications. The clock is ticking to properly secure your lines of internet communications, standard bodies and web browsers have put out their warnings, and there is no time like to present to get up to speed.
[*] The latest version of TLS (Transport Layer Security) is 1.3; see RFC 8446.
(Score: 2) by coolgopher on Friday July 17 2020, @10:39AM (8 children)
How do you make sure you talk to the right https server and not some imposter injected by your ISP via DNS and route hijacking?
(Score: 0) by Anonymous Coward on Friday July 17 2020, @11:19AM (4 children)
RFC 1149 [ietf.org] FTW!
(Score: 2) by hendrikboom on Friday July 17 2020, @11:29AM (2 children)
I see. The pigeons know. And a pigeon hunter isn't likely to pick up enough packets to form a meaningful message?
(Score: 0) by Anonymous Coward on Saturday July 18 2020, @06:17AM (1 child)
That's why it's necessary to use strong encryption with large keys. ;)
(Score: 0) by Anonymous Coward on Monday July 20 2020, @01:42PM
Large keys?
We talking a good 20g here, 100g, or some half kilogram whopper from the medieval ages?
(Score: 3, Insightful) by coolgopher on Friday July 17 2020, @11:32AM
And here I was expecting a link to RFC3514 [ietf.org] instead.
(Score: 2) by hendrikboom on Friday July 17 2020, @11:27AM
Because my browser does do https.
(Score: 2) by Opportunist on Friday July 17 2020, @12:32PM (1 child)
By checking whether the certificate matches the page. As long as you didn't somehow manage to inject your certificates into my browser store, it's pretty trivial to verify whether the certificate presented belongs to the server.
(Score: 2) by coolgopher on Monday July 20 2020, @01:05AM
Yeah fair point, it does take quite a bit more effort to pervert the initial set of top level certificates. Then again, time and time again we find about CAs that have been handing out certs willy-nilly >.<