On last day as president, Obama's CIO shrouds future .gov websites in secret code On United States president Barack Obama's last day in office, the U.S. Chief Information Officer and the Federal CIO Council have announced a new rule that will see all future .gov websites shrouded in impenetrable secret codes. Sorry, alt.right readers, there's nothing sinister about it: the CIO has announced that its policy …
That's not me, but it reads like a challenge to turn the story into a conspiracy theory. So here goes. Not actually one I find plausible, but could be tweaked ...
When .gov websites enforce their own rules and only work with browsers that have an NSA backdoor, it'll help weed out privacy.
While it may not be sinister, and has the opportunity to make communication more secure, there is also another problem buried in how https works. Part of setting up a secure connection requires your browser to send its public key to the server to use to send back the symmetric encryption key to your browser. This key does not change except sometimes when your browser gets 'updated'. That public key is the same key used when setting up https connections to all other browsers. This information allows those tapping networks to track where connections are being made and by whom without having to be directly attached to your connection. Just look at the key being used to set up the SSL connection - See Diffie-Helman key exchange of example.
I hope browsers are going to start using a different public key for each website.
Can you expand more on this? As I understand it, the server is the only one sending a public key, along with its certificate. The browser checks the certificate is trusted, then uses the public key the server sent it to encrypt a random symmetric key along with the HTTP URL/request. The server uses its private key to decrypt that, and then uses the symmetric key to encrypt the response, which the client finally decrypts on its end using the symmetric key.
"As I understand it, the server is the only one sending a public key, along with its certificate."
That's because you seem to understand PKI, while just_me does not.
What he's referring to is a thing (it's the justification for the existence of TOR, the fact that encryption alone does not prevent you from seeing who is talking to who and when they are talking to each other), but it's waaaaaaaaay outside the scope of PKI or encryption to deal with it. Using randomly-generated keys for each session can't provide any extra security in that regard; only varying the route via a hidden series of hops (like TOR) can.
@just_me: the browser doesn't send a key (except for very secure sites, where the server asks for a certificate from the browser to prove the browser's identity - not relevant, since the vast majority of us don't have certificates and don't try to connect to these sites anyway).
1 - the server identifies itself by sending a certificate, which includes the server's public key
2 - the browser/client decides on a secret (symmetric) key to be used for the actual browsing part of the transaction (the second phase). It then encodes this using the public key sent by the server, and sends the result to the server
3 - the server decodes the new symmetric key using its own (the server's) private key
4 - Both the client and the server now know the secret symmetric key to be used for encryption.
So, basically, asymmetic keys (different public/secret keys) are used to decide on a symmetric key (one secret key) to be used for subsequent encryption. During the asymmetric phase, only the server's public key is used.
It's standard in most browsers - they pre-load all the major sites which enforce HTTPS (i.e. use HSTS) - FB, Google, any reputable webmail service, etc.
The CIO is simply saying they will submit their sites to the HSTS Pre-load list.
Nothing sketchy about that - your browser has records pre-loaded for thousands of sites you don't use so a MITM cannot direct you to an HTTP clone the first time you use it.
From a story in the Reg's related list :
"Additionally, Hourclé warns of the effect the policy may have on those without computers at home, as many public institutions which offer internet access are mandated to filter it by state or local laws and may block HTTPS entirely."
So will we have the situation where you can't use web access in a public library to connect to a government website ?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
