Difference between revisions of "TLS"

From MgmtWiki
Jump to: navigation, search
(Cryptographic Issues)
(Cryptographic Issues)
Line 44: Line 44:
  
 
* [https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-03-20-minutes.md WebAppSec WG - 2024-03-20] reported on implementation of EC 35529 an issue with rejecting small order points. Mozilla requested, didn't get push-back on the spec, but my understanding is that Chromium prefers to ship their implementation of x25519 as it is. Technically also not conformant to the RFC. But wider issue applying also to [[TLS]]. Discussion needs to happen in CFRG about the behavior. W3C might not be the right place to have those conversations.
 
* [https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-03-20-minutes.md WebAppSec WG - 2024-03-20] reported on implementation of EC 35529 an issue with rejecting small order points. Mozilla requested, didn't get push-back on the spec, but my understanding is that Chromium prefers to ship their implementation of x25519 as it is. Technically also not conformant to the RFC. But wider issue applying also to [[TLS]]. Discussion needs to happen in CFRG about the behavior. W3C might not be the right place to have those conversations.
* The CFRG has also been exploring the adoption of new elliptic curves. Curve25519 has been proposed, but it’s essential to consider its suitability beyond just TLS (including SSH, IKE, etc.) The CFRG aims to achieve re-usability across various protocols.
+
* The Crypto Forum Research Group (CFRG) has also been exploring the adoption of new elliptic curves. Curve25519 has been proposed, but it’s essential to consider its suitability beyond just [[TLS]] (including SSH, IKE, etc.) The CFRG aims to achieve re-usability across various protocols.
 
* [https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptography-standards/documents/papers/session4-costello-craig.pdf A brief discussion on selecting new elliptic curves] is a report from Microsoft research. " This position paper summarizes our perspectives on the selection of next-generation elliptic curves for standardization. It also contains generation algorithms intended as a foundation for choosing elliptic curves for cryptography in a simple, consistent and rigid way"
 
* [https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptography-standards/documents/papers/session4-costello-craig.pdf A brief discussion on selecting new elliptic curves] is a report from Microsoft research. " This position paper summarizes our perspectives on the selection of next-generation elliptic curves for standardization. It also contains generation algorithms intended as a foundation for choosing elliptic curves for cryptography in a simple, consistent and rigid way"
  

Revision as of 13:04, 26 March 2024

Full Title or Meme

Transport Layer Security (TLS) creates a tunnel between two parties using TCP/IP, typically also using HTTP.

Context

The more recent versions of SSL - secure sockets layer code. Renamed due to Microsoft's distaste for code created by competitors.

Identifiers

TLS is designed to create a secure tunnel between two parties at the transport layer and hence identification is of the transport end-points. Channel Binding (qv.) is a method to bind the application end-point, or even the actual Entity at each end-point to the security created from those two transport layer Identifiers.

Sequence

Client Server Notes Misc
TCP Syn to port 80 or 443 Synchronize sequence nos
SynAck Synchronize-Acknowledgment
Ack acknowledges SYN-ACK
http get port 80 client can skip to https
html 301 to client port Redirects client
client hello supported versions & ciphers
server hello selected version (1.3) ciphers & rand no
server cert to prove its identity
client secret encrypted with the public key of server
client finish https complete session key = rand no + client secret

TLS 1.3 is faster and more secure that 1.2. It is even faster on reconnection if the client remembers a server random number from before and thus skips the hello exchange.

HSTS

(HTTP Strict Transport Security)

Implementing HSTS is crucial for long-term security. It instructs browsers to remember to only use TLS when connecting to your site in the future. Note that even if connections to port 80 are insecure, HSTS will automatically redirect clients from port 80 to port 443 without attempting to connect over port 80.[1] M-15-13 calls for “all publicly accessible Federal websites and web services” to only provide service through a secure connection (HTTPS), and to use HTTP Strict Transport Security (HSTS) to ensure this.

Cryptographic Issues

  • WebAppSec WG - 2024-03-20 reported on implementation of EC 35529 an issue with rejecting small order points. Mozilla requested, didn't get push-back on the spec, but my understanding is that Chromium prefers to ship their implementation of x25519 as it is. Technically also not conformant to the RFC. But wider issue applying also to TLS. Discussion needs to happen in CFRG about the behavior. W3C might not be the right place to have those conversations.
  • The Crypto Forum Research Group (CFRG) has also been exploring the adoption of new elliptic curves. Curve25519 has been proposed, but it’s essential to consider its suitability beyond just TLS (including SSH, IKE, etc.) The CFRG aims to achieve re-usability across various protocols.
  • A brief discussion on selecting new elliptic curves is a report from Microsoft research. " This position paper summarizes our perspectives on the selection of next-generation elliptic curves for standardization. It also contains generation algorithms intended as a foundation for choosing elliptic curves for cryptography in a simple, consistent and rigid way"

Certificate Authority Issues

There are approximately 85 organizations authorized to issue TLS certificates for the web today. And seven of them issue 99% of all certificates currently in use. The presence of the others is largely intended to accommodate web openness and national sovereignty—an admirable goal, albeit one that introduces a significant attack surface for every web user.

But were you aware that the recent EIDAS 2.0 legislation, that was just signed, will obligate browsers to trust all QWAC-approved CAs listed on the EU Trust List (https://esignature.ec.europa.eu/efda/tl-browser)? To illustrate, Spain has 13 CAs approved to issue these certificates and there are 27 member states in the EU. Additionally, did you know the legislation will not permit browsers to remove of CA with a history of repeated incompetence without government approval?

The most famous of all CA distrust events was an EU CA known as DigiNotar, and those in the PKI space might say that 12 years ago and today, the Conformity Assessment Bodies would have caught that and dealt with it proactively. But is that true? Check out the history of Camerfirma (https://wiki.mozilla.org/CA/Camerfirma_Issues) and wonder why an organization with such poor operational practices that the internet isn't dependent on is still trusted by anyone? Then ask why the associated CAB still lets it be approved as a CA for issuance.

For those who say that the web doesn't need Browsers for such actions, consider this recent incident involving a Turkish CA (https://bugzilla.mozilla.org/show_bug.cgi?id=1801345). And for those who doubt governments would use CAs to gain visibility into web traffic, take a look at this case where a French CA was doing just that: https://arstechnica.com/information-technology/2013/12/french-agency-caught-minting-ssl-certificates-impersonating-google/.

Supposedly the final text has a recital that was added to the language to suggest that the scope of these requirements is to be limited to trusting these CAs for identity information and not the domain but the document is still private so we don't know for sure. Even if true recitals are not binding and the bill has other issues, for example, it requires browsers to reinstate user interface that has been proven to be harmful and misleading to users. https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/.

It also prevents the Browsers from establishing additional requirements for the CAs above and beyond what is included in the associated EU legislation, for example, they won't be subject to http://certificate.transparency.dev which has helped catch many many issues. All this means calcifying the web making it impossible to move forward without legislative change and leaving the web less secure at the same time. Change will now be governed by regulators, lobbyists, and standards boffins that either benefit from this weakening of the web or have no accountability for its consequences.

There are 195 sovereign nations in this world. each would love to be in a position to observe everything their citizens and everyone who interacts with them does. When the world's most liberal and democratic governments put into place the tools to enable mass surveillance and weaken internet security in this fashion what makes us think the rest won't as well.

Originally from a post by Ryan Hurst.

References

  1. US CIO, Compliance Guide https://https.cio.gov/guide/

Other Material=

  • See wiki page for OpenSSL for open source code implementations of TLS.