Slashdot Mirror
EFF Applauds 'Massive Change' to HTTPS (eff.org)
"The movement to encrypt the web reached milestone after milestone in 2017," writes the EFF, adding that "the web is in the middle of a massive change from non-secure HTTP to the more secure, encrypted HTTPS protocol."
In February, the scales tipped. For the first time, approximately half of Internet traffic was protected by HTTPS. Now, as 2017 comes to a close, an average of 66% of page loads on Firefox are encrypted, and Chrome shows even higher numbers. At the beginning of the year, Let's Encrypt had issued about 28 million certificates. In June, it surpassed 100 million certificates. Now, Let's Encrypt's total issuance volume has exceeded 177 million certificates...
Browsers have been pushing the movement to encrypt the web further, too. Early this year, Chrome and Firefox started showing users "Not secure" warnings when HTTP websites asked them to submit password or credit card information. In October, Chrome expanded the warning to cover all input fields, as well as all pages viewed in Incognito mode. Chrome has eventual plans to show a "Not secure" warning for all HTTP pages... The next big step in encrypting the web is ensuring that most websites default to HTTPS without ever sending people to the HTTP version of their site. The technology to do this is called HTTP Strict Transport Security (HSTS), and is being more widely adopted. Notably, the registrar for the .gov TLD announced that all new .gov domains would be set up with HSTS automatically...
The Certification Authority Authorization (CAA) standard became mandatory for all CAs to implement this year... [And] there's plenty to look forward to in 2018. In a significant improvement to the TLS ecosystem, for example, Chrome plans to require Certificate Transparency starting next April.
Browsers have been pushing the movement to encrypt the web further, too. Early this year, Chrome and Firefox started showing users "Not secure" warnings when HTTP websites asked them to submit password or credit card information. In October, Chrome expanded the warning to cover all input fields, as well as all pages viewed in Incognito mode. Chrome has eventual plans to show a "Not secure" warning for all HTTP pages... The next big step in encrypting the web is ensuring that most websites default to HTTPS without ever sending people to the HTTP version of their site. The technology to do this is called HTTP Strict Transport Security (HSTS), and is being more widely adopted. Notably, the registrar for the .gov TLD announced that all new .gov domains would be set up with HSTS automatically...
The Certification Authority Authorization (CAA) standard became mandatory for all CAs to implement this year... [And] there's plenty to look forward to in 2018. In a significant improvement to the TLS ecosystem, for example, Chrome plans to require Certificate Transparency starting next April.
If a website doesn't take any private information from you why does it need ssl/tls?
I'm just not understanding the push for everything to be encrypted when it doesn't need to be.
In my professional judgement, there is little benefit to https for many sites, which simply present publicly available information. This is based on my 20+ years of internet security work throughout my career. Payment pages where people enter credit card information obviously need encryption, but in my opinion most sites see little to no benefit.
Https means it can't be loaded from your ISP or company's cache, making popular sites slower. It also prevents corporate security or your own router / firewall from seeing the malware or whatever that some hacker added to the page, and generally keeping an eye out for security problems. For public sites where you don't log in, I think https is a net reduction of security.
There *is* the argument that it makes it harder for governments to know which pages you're viewing on a site, but they still see which sites you connect to.
As I understand it, corporate security has the option of having you accept their keys and MITMing everything, allowing scanning and caching of activity performed from inside the corporate network. Is that incorrect?
Worth emphasizing that any time you have a user login, you should probably be using https to protect your cookies from then on, otherwise the cookies can be hijacked with a bunch of different methods.
"First they came for the slanderers and i said nothing."
So you've got 20 years of professional experience yet don't recognize the dangers of MITM attacks from non-HTTPS pages?
If you are connecting to an unprotected page basically nothing on it can be actually trusted. While a page might look normal every resource and link could have been rewritten to do something malicious. You have no way of knowing that anything loaded over HTTP is what the server actually intended to send.
Links could route through fishing sites and malicious resources could be added. One of the best features of HTTPS is to make resources resistant to MITM attacks. An page with no PII can be intercepted and modified to leak that data without you even knowing.
Most people don't want or need their ISP or corporate gateway caching content. For one a browser's cache is more effective for most content since it's loaded from disk (or RAM) rather than coming over a network. Second it's more effective for ISPs to forego their own caching and simply let CDNs with their colocated edge caches handle the task. The content from the CDN to client is going to be encrypted using the source site's credentials (or authorized credentials) so end users can trust the data path to the server and the ISPs don't need to pay for the hardware. Since CDNs colocate edge caches everywhere they can afford there's little if any performance difference between a third party edge cache to the client and an ISP's edge cache to a client. They're likely to be hosted in the same buildings on the same networks.
I'm a loner Dottie, a Rebel.
Now if only browsers would isolate resources from third party web sites so they can't scrape info from other parts of the page or grab keyboard/mouse input, and allow per-page access to certain hardware like mic/camera/filke system, then it would go much further.
Https stops ISPs and nodes from tapping info, but a lot of third parties end up with all of that anyway.
Twinstiq, game news
Comment removed based on user account deletion
HTTPS prevents tampering with the connection. Even if nobody cares about your family pictures, someone cares about the opportunity that you give them to modify the content sent by your server before it reaches your relatives, do some social engineering at their expense (they’ll be convinced that whatever they see comes from trusted you) and get them to fall for a phishing trap or install malware. By serving through HTTPS, you are adding some protection for your relatives.
You just watch. In five years the major Web sites, having switched to HTTPS-only, will require personal SSL certificates to use their services. You think Google and Facebook track you now? Just wait until they can tie a browser session with your personal identity with virtual certainty.
Exactly what was this massive change to HTTPS? Was HTTPS insecure in some way and needed to be fixed? Oh wait, what you probably meant was EFF Applauds 'Massive Adoption' of HTTPS.
Better known as 318230.
Not just governments spying on you, but your own ISP and advertisers too. We have already seen lots of ISPs doing MITM attacks that insert unwanted content into pages.
Being able to see that you connected to Wikipedia is very different from being able to see that you looked at the Wikipedia page on STDs or pressure cookers or Casio watches.
Organisation level caching is overrated these days anyway, since so much content is dynamic anyway. The benefits far outweigh the costs, especially considering that people who really need caching can just install their own certificates on their undoubtedly centrally managed computers.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
That is an option. If corporate administers the computers, they can install a cert onto every computer which lets them (and anyone who gets their key) mitm ALL otherwise secure connections. Meaning NO connection is secure.
Personally, that seems to me a high cost to pay. My preference is that my employer's firewall can keep an eye out for malware added to public sites, but they don't mitm my secure connections and see the content of my personal Gmail, or my banking passwords.
I prefer to apply rules appropriate for different kinds of sites - news sites and banking and email are different. I'd like my secure connections to be secure, so nobody can Snoop on them. I'd like malware protection for sites where encryption is pointless.
HTTPS is easily broken by the NSA if you use any official signing authority except perhaps Let's Encrypt
Um, no. You do know that signing authorities only sign the public part of your key, right? You don't give them the private part of the key.
Encryption fixes many problems caused by plain-text HTTP and is fully worth doing everywhere. It's true that there are some problems that HTTPS doesn't fix, but that is not a good reason to not use it.
Sure HTTPS prevents MITM attacks from compromising your browser, but for most sites it does nothing to hide what you are browsing. Crawl a site and fingerprint the packet size and timing of requests, and you can easily compare that a captured trace of your target.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
The PROBLEM is that this is pure security theater to make people feel safer! HTTPS is easily broken by the NSA
Not true. Without HTTPS, an attacker needs the ability to inspect traffic on one hop between you and the server. Stick a tap on a bunch of data centres and you've got pervasive monitoring. With HTTPS, an attacker has two choices:
Option one, they can compromise the server's private key. This requires either cooperating with the provider (if you can lean on them with a national security letter or similar), or hacking the server and exfiltrating the key. There's nothing you can do about this kind of attack, but it's infeasible to do this on all connections.
Option two, they can do an active MITM attack, where they send a valid cert to you, which is signed by a trusted CA that they can lean on to provide arbitrary certs. There are a bunch of defences against this, but the simplest is Certificate Transparency, which makes it easy for you to see that the cert that you're seeing is not the cert that everyone else is seeing. For example, you can check the logs for Slashdot and see that they're using Let's Encrypt, but there seems to be a slightly suspicious cert issued by Amazon that some people are seeing. Chrome integrates these checks, so will warn you of suspicious activity and the server administrator can inspect them and see if any of their users have been attacked in this way. You can also now add CAA records to DNS that indicate which CAs should be trusted for your domain (only useful if you use DNSSEC), which means that they'd have to lean on a specific CA - if you get your cert signed by a US CA, then it's unlikely that the FSB or Chinese intelligence agencies will be able to get a fake certificate, for example.
If you think turning an easy passive attack into a difficult active attack is security theatre then I hope you never work in security.
I am TheRaven on Soylent News