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.
...when our toasters and refrigerators are plotting against us?
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.
You know a technology is really ubiquitous when even a tech news site switches to it. Maybe, perhaps, I will see working Unicode on Slashdot within my lifetime. For dig -t AAAA slashdot.org returning something else than NXDOMAIN, though, my hopes are not so high.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
"he 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"
HSTS headers are ignored if a connection is made over HTTP. In order to take advantage of HSTS you must first connect to the site over HTTPS, after which point your browser will prevent you from accessing the site over HTTP. Some browsers have STS preloaded lists which will prevent you from connecting to a site that is well known to use HSTS but this won't work for every site and will definitely not work for every browser.
To quote RFC 6797:
Bootstrap MITM (man-in-the-middle) vulnerability is a vulnerability
that users and HSTS Hosts encounter in the situation where the user
manually enters, or follows a link, to an unknown HSTS Host using an
"http" URI rather than an "https" URI. Because the UA uses an
insecure channel in the initial attempt to interact with the
specified server, such an initial interaction is vulnerable to
various attacks
It's all "secured" by Let's Encrypt. There is no diversity, no fallback. It doesn't solve the problems with a certificate system that allows any trusted CA to issue certificates for any domain. Let's get DANE into browsers.
Aweeeee look! We got snowflakes melting for the new year!
So, just as the 'net is making major moves to https, I see this on /., "EFF Applauds 'Massive Change' to HTTPS"! Really?
Why are they changing it now that the majority of sites are using it? Don't they know that massive changes just as people are adopting it can kill a protocol? People will move on to something that "just works". Why don't they leave it alone until most everyone is using it and gets used to it, then make their massive cha...
What? There is no massive change to https? TFA is talking about people talking about old news?
Never mind.
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
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."
funny, I have only 17 years of infosec experience and I wholeheartedly approve of this. For the Corp environment we do TLS inspection, so beaconing and C2 is detectable but forcing TLS everywhere, all the time, makes it to where when applications change over time... as they always do... and then they start hitting PII or GDPR or Crown Jewels any other category of data, we donâ(TM)t have to care about transit. No questions asked, no exception, TLS only
The EFF got it right in their report. It is irrelevant whether half the 'net is transported over https, as some other protocol may well displace it and http (eg whatever netflix uses for streaming its movies).
Many connections are so fast now, there's no need to do MITM caching. Can't remember the last time my ISP actually cached a website. Maybe Netflix, but only because they pay for it. Most heavy websites do local storage and service workers.
So now in this brave new world you are required to be 'certified' to put up a web site.
Why does an organisation with 'freedom' in their name applaud this?
The problem is, any page that *links* to a login page, or credit card entry page, can be MITM-ed over HTTP to change the link to something malicious.
I also don't buy the other two arguments, all browsers now cache HTTPS content, and while that may not be as good as ISP/company caches, it's still fine. Corporate security also tends to be MITM-ed with pre-installed certificates on client machines.
Who needs government we worship when a corporation or authority that gives certs can just invalidate any very whoâ(TM)s owner they donâ(TM)t like.
HTTPS prevents tampering. How many times must this be repeated?
This https movement is just backlash from people becoming aware everything was being spied upon by the USA. A bigger deal outside the USA; allies and enemies all being spied upon.
The PROBLEM is that this is pure security theater to make people feel safer! HTTPS is easily broken by the NSA if you use any official signing authority except perhaps Let's Encrypt, but somehow I doubt that was setup as NSA proof. It's not that you are being broken into all the time; only targeted people are being broken - so it's better than previously... although the greater the targeting ability the more people will be targeted and for a longer period.
The major problems with XSS, server breaches, malware, TRACKING, etc. are not stopped by HTTPS-- it's just 1 network layer of protection, there are other layers to attack it does nothing to help with. It only protects a narrow domain of problems while coming at a much greater cost of CPU and bandwidth that somebody should calculate the CO2 footprint for... (while they are at it the DRM overhead on HDMI would be nice to know as well... since it's a stupid waste as well.)
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
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.
Why don't you come connect to my wifi hotspot, and log into all your sites unencrypted? I'll even cache the pages for you so reloads are faster. Even better, you can use my local DNS server.
Oh, you don't want to connect to my hotspot? Well why not just connect to your home wifi network, that just magically appeared at Starbucks.
The Daddy casts sleep on the Baby. The Baby resists!
Comment removed based on user account deletion
"harder for governments to know which pages you're viewing on a site" is dumbest argument ever made(who every said that is a idiot). The government just scapes the page themselve and makes whatever judgment before the last package reaches the user.
It is correct, corporate does MITM if it wants access for that sort of thing.
In my professional judgement, there is little benefit to https for many sites, which simply present publicly available information.
Your professional judgement is wrong, because you're only looking at half of what HTTPS provides. Encryption is only one of the things HTTPS provides, and it's arguably the less important one. Integrity is the more important one. HTTPS ensures that you're connecting to the site you think you are, and that the content it provides arrives at your browser unmodified.
Without this, if a malicious party can get access to your connection at any point between your browser and the server they can make arbitrary modifications. They can inject malware that exploits vulnerabilities in your browser and OS, they can inject ads, they can inject tracking cookies, etc.
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.
Nonsense, especially for the corporate cases. You can install proxies that do caching and content inspection by pushing custom certs to all of the client trust lists. This also allows the proxies to control which CAs and sites are trusted, rather than relying on whatever happens to be shipped with the clients.
In the ISP case, nearly all ISP-based caching today that actually offers any value is done by co-locating servers with the ISPs. Most ISPs of any size have Akamai and Netflix servers. These servers, of course, have access to the relevant certs.
For public sites where you don't log in, I think https is a net reduction of security.
Nope. Plain HTTP is bad and should die.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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?
Indeed. And with HTTPS, corporate security can ensure that they're the only ones MITMing the connection. With HTTP it's impossible to know if anyone else might be monitoring -- or even modifying -- the connection.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
Keep in mind that any given site you access could be compromised, thus being rewritten to do something malicious. And since PII leaks like a sieve out of sites even with HTTPS (like Google, Facebook, etc.) it's not like the encryption really buys you privacy either.
dom
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
Many connections are so fast now, there's no need to do MITM caching
Every time a fool advocates for changes for everyone because the internet appears to be fast enough at his personal ivory tower he must be reminded of what it looks like in the suburbs. And third world countries. And mobile browsers basically worldwide.
On mobile devices the effect is componded. Devices forever loading megs and megs of third party javascript tracking code, useless css and images in very improper amounts of ram (and how quickly the OS decides the page needs to be swapped out and fully reloaded from scratch yet again, for added pain) waste unknown man-hours because the web has been crippled as a tracking delivery platform rather than the humble beginnings as an information delivery one.
A page view with a dam providing the proper non-trivial adblock and hostfile fixes might load in a second, but it takes several times that much for everyone else even if much data is "cached" by your browser, router's DNS or ISP. A lot of code out there is made so it'll check for new content on every load (how else do you think they'd give us changing ads for every rotation, if not for dynamically reloading content we don't really need?)
On mobile, even HTML loaded from file:// still can take an unacceptable second or two loading *in AIRPLANE MODE*, because parsers are braindead. So, NO. If things on airplane mode are this bad for a non-trivial part of the modern world (almost 40% of traffic is smartphones, which is normally not going to be flying at the comfortable speeds you may see at home)
You missed the other advantage, even though you stated it. It can't be served up by a (potentially modifed) "cache". It's about integrity as well as privacy.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
So many sites don't get their certificates right (self-signed, wrong domain, wrong subdomain/no wildcard, expired, etc etc). Which results in some stupid blog being completely inaccessible unless I hack my browser into connecting over plain HTTP despite the HSTS setting. Most web connections don't need to be secure, because I don't even know the site (got there via search), I don't submit any data, it's not illegal, so all I care for is the content I see.
Yeah. Too many people are forgetting that endpoint-to-endpoint encryption doesn't protect the endpoints themselves. I think this push towards universal HTTPS is yet another security theater---it makes you feel securer than you ought to feel.
Almost everything you said is wrong.
"Https means it can't be loaded from your ISP or company's cache, making popular sites slower."
1. Most large companies setup a proxy for their employees to use. They install a company certificate on their employees' work PCs and company laptops. The company proxy authenticates employees for outside http/https access, MITMs the SSL certs which then allows the company to both inspect the traffic and cache it.
2. Popular websites are highly dynamic. Much of the content is not cache-able. The parts that are cache-able are probably already in your web browser cache.
3. If you are using an ISP that attempts to alter via caching or otherwise your web traffic, you need a new ISP.
"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."
Wrong. See point #1 above. Name any security/anti-virus company that makes web proxy software and they probably support an SSL intercept feature.
What SSL does prevent is third parties (ISP, upstream ISP/Telco, Government entities) from performing MITM attacks and inspection of your connection.
Captcha: phosgene
No it doesn't. How many times must you be corrected. More complicated does not mean more secure.
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.
> Too many people are forgetting that endpoint-to-endpoint encryption doesn't protect the endpoints themselves.
Noone who knows anything significant about TLS has forgotten that TLS protects nothing but the communication channel between two endpoints.
> I think this push towards universal HTTPS is yet another security theater...
It solves a very real problem: Undetectable snooping on and/or content modification by a man in the middle. Just ask any Comcast customer how pleased they are with the poorly coded "Upgrade your modem!" or "There's going to be an outage in your area!" notices injected into their unencrypted HTTP sessions.
The integrity aspect of TLS is a important, that's a good point. In many cases where there isn't PII involved it doesn't matter much - the RC drone page where I'm reading about quadcopters is more likely to be hacked or have malicious code / ads than it is to be MITM, but it's something worth considering. The question is "which is a more likely threat, a mitm or a hacked WordPress?" I can tell you a hacked WordPress plugin occurs thousands of times more often than a malicious mitm, so content inspection will improve security better than to will, for sites people *read* rather than log in and do stuff. Both are *theoretical* risks, hacked Wordpress plugins are truly a constant daily occurrence in the real world.
Mitm by Corp sec 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. Corpsec then sees your personal email, your banking password, etc - as does anyone who gets the corporate cert. That's an important cost to consider.
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.
>Your professional judgement is wrong,
You are normally smart enough to have interesting conversations in which you recognize that other people, people with decades of experience in their field, can see something differently than the way you see it. Typically you recognize that 20 years of practical experience, of dealing with attacks every day, might allow someone to learn something that didn't immediately come to mind.
You are a moron
nobody thinks TLS protects an endpoint.
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.
Indeed.
Think about it for a second - apparently a popular use of Let's Encrypt is to provide SSL certificates for Paypal phishing sites - something like 14,000 certificates have been issued.
If it wasn't for the fact that many top-notch organizations back Let's Encrypt like the EFF, one reasonable approach might be to mark all Let's Encrypt sites as untrusted.
yes, it does. If you have proof otherwise put up or shut up.
Https means it can't be loaded from your ISP or company's cache, making popular sites slower
Talk to ISPs. This was a huge deal 10-15 years ago, when the popular subset of the Internet was small enough to fit into caches. Now, the vast majority of fetches miss in caches anyway and a lot of ISPs have stopped running them. With a fast link, the overhead of having to do two TCP handshakes (one to the cache, then one from there to the real site when it misses) plus the latency of forwarding the response via userspace outweighs the gains, so even if your ISP is running a caching proxy, you'll probably find that it's faster to not use it.
The things that consume a lot of bandwidth these days are videos and these are distributed via a CDN, which will have an endpoint in your ISP's POP or one hop away at their upstream exchange. And these support HTTPS. Netflix, for example, is around 30% of all US Internet traffic and now sends all of their data over HTTPS (from OpenConnect appliances running FreeBSD, able to serve 40Gb/s on a single core using HTTPS). YouTube is typically the same, though this benefits less from caching because there's more of a long tail (a huge number of Netflix viewers watch the same things, so it does get some benefit from caching, and they fetch the most popular shows to the caches in advance).
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
Absolute nonsense. It prevents an attacker from performing a MITM and injecting malware. This includes ISPs (or anyone who controls one of the hops between you and the server) injecting ads into web sites that you visit (which has happened).
If the attacker controls the endpoint, then they can force you to use HTTPS anyway by sticking in a 302 response code in the HTTP request, so you lose nothing from having non-malicious sites use HTTPS as well.
You're describing a setup where network security relies on perimeter security (bad idea) and where perimeter security relies on the attacker cooperating and sending readily identifiable malware in plaintext. That setup would fail a security audit by anyone moderately competent.
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.
Nope, they'll see which IPs you've connected to, and possibly which DNS queries you've made (though that depends a bit on TTLs and caching). With a lot of sites hosted using vhosts, the IP doesn't tell you very much. You are right that there's more to be done on DNS cloaking. You are wrong that the only adversary of note is a government though - your ISP (who, in the US, is now allowed to collect and sell this data to third parties) can record every site that you visit.
I am TheRaven on Soylent News
Doesn't work very well these days, for a lot of sites. HTTP 2 allows requests to be pipelined on one connection, with compression. With dynamic content and browsers selectively blocking certain content (mostly ads) it gets tricky.
Having said that, it would be a good idea to randomly pad packets.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I personally don't think the blanket https-ing of everything is such a great idea.
One major issue which I have run into is backwards compatibility - Old platforms can no longer access large parts of the Web because their browsers can't talk to encrypted-only hosts, esp. ones that have disabled all but the newest TLS/SSL standards.
Already this is forcing the use of an increasingly shrinking number of browsers, narrowing the gene pool yet more.
Many sites I can no longer access on an Amiga or even on Presto-engined Operas (The last of the Good Operas)
Another issue is the waste of energy - For instance, I was reading an article about how, back in the day, hotmail only encrypted the login but not the rest of the session as it was so incredibly computationally expensive.
This will not have changed - We have newer and faster CPUs that can cope, but this suggests that https is still much more expensive on CPU power than http - How much energy are we wasting, encrypting everything no matter what it is?
Anyhow, https is nearly free - why shouldn't it be used everywhere all the time?
Because don't CAs don't issue certificates for 192.168/16 or the mDNS reserved domain (.local), HTTPS between devices on your LAN requires either buying a domain or running your own CA and installing its root on all devices on your network. The latter is difficult on many platforms.
Many connections are so fast now, there's no need to do MITM caching.
And many aren't, particularly in places like sub-Saharan Africa where you might have 25 people sharing a 128 kbps link. What's worse: someone seeing what Wikipedia articles you're reading, or not being able to read them at all because your ISP hit its daily cap downloading separate copies of the article for other users?
[Let's Encrypt] requires a little extra setup work on the part of the webmaster but, other than that, what great problems do you see with that scheme?
I see two problems.
One is with web hosting that charges more to install a third-party certificate than to purchase and install a certificate issued by the CA that the hosting provider resells. One example of this is Volusion, an e-commerce host.
Another is sites on your local area network (LAN). Like other CAs trusted by your browser, Let's Encrypt issues certificate only to the owner of a domain, not for hosts in 192.168/16 or .local, and there are severe rate limits that affect users of the free subdomain that a dynamic DNS service may provide. A lot of heads of household don't want to have to buy a domain and keep it renewed just to put up a router, printer, or NAS on a home network.
So now in this brave new world you are required to be 'certified' to put up a web site.
That's been the case since the Internet was available to the public. How often do you use a literal IPv4 or IPv6 address to visit a public website without getting it "certified" by a domain registrar? Once you own a domain, Let's Encrypt is willing to issue a certificate without charge.
Then what should I do for integrity and authentication without confidentiality, so that an intermediate cache can preserve the integrity and authentication properties?
I do know what corp sec is doing. I know which products they use, and many of them are in-house, so I have the source code. (We're a security company, and eat our own dog food.)
Anyone reasonably competent can see if their employer has pushed a trusted certs that allows them to mitm all TLS connections. My last two employers have not.
It solves a very real problem: Undetectable snooping on and/or content modification by a man in the middle. Just ask any Comcast customer
Blocking attacks like those of Comcast requires Integrity and Authentication but not Confidentiality. Confidentiality on public websites makes it far harder logistically for, say, a school to run a caching proxy for the benefit of its students and faculty.
HTTPS provides all of Confidentiality, Integrity and Authentication.
Cleartext HTTP provides none.
What provides Integrity and Authentication without Confidentiality?
apparently a popular use of Let's Encrypt is to provide SSL certificates for Paypal phishing sites
Apparently a popular use of Namecheap is to provide domains for PayPal phishing sites. Why not mark Namecheap as likewise untrusted, and continue to distrust registrars one by one until only the most expensive registrars remain?
Second it's more effective for ISPs to forego their own caching and simply let CDNs with their colocated edge caches handle the task.
Provided your ISP can afford a large enough uplink to the Internet to reach the CDN's nearest edge cache. Say you operate IT for a school in sub-Saharan Africa behind an ISDN (0.13 Mbps) connection to the Internet, and you want to let all 25 students in a particular classroom read a particular Wikipedia article. The CDN's nearest edge cache is on the other side of your connection. Under cleartext HTTP, your caching proxy could retrieve the article once on behalf of all devices on the network and then serve it up to students' devices. HTTPS inflates this by a factor of 25 because the nearest cache must serve the article across that link 25 times. Would it be better to add a private CA and HTTPS MITM to your caching proxy in order to continue achieving the 25-fold reduction in Internet data volume?
3. If you are using an ISP that attempts to alter via caching or otherwise your web traffic, you need a new ISP.
Many people who need a new ISP are unable to meet that need because meeting that need would require moving to a different city or even a different country.
Automatic race baiting. Give this lightweight a flamebait to start out. Maybe a funny and two trolls to affect his karma productively.
Every single f'ing day, I find I can't connect to some website that really really really does not need encryption, because there is some certificate screwup. Every day. Every. Day. HTTPS everywhere, enforced by Dracon, is not ready for prime time.
> What provides Integrity and Authentication without Confidentiality?
That's a softball. Digital signatures.
> Confidentiality on public websites makes it far harder logistically for, say, a school to run a caching proxy for the benefit of its students and faculty.
So?
a) Have you _used_ the modern internet in the past five years? A _ton_ of content is dynamically generated. On-site caches are far less useful than they were at the turn of the century.
b) If you _must_ have on-site caching, use the "Corporate MitM" features built into every major web browser to MitM and cache.
c) CDNs and big content providers are _more_ than happy to install content caches on site if your site is large enough.
Well......that depends on how the pages are designed.
If the page exposes nothing but the base URL, (i.e. navigation data is not exposed in the URI, but managed through variables) then nothing except the base URL is ever trackable when the data is encrypted via HTTPS.
IMO we should also be pushing for more development that works this way. Sure -- allow the creation of deep links, but immediately reload using non URI-exposed variables.
There is little hard to sending everything over HTTPs and it takes users (who won't know any better) out of security decisions. Everything's encrypted. They don't have to think. "Well, I'm only entering what high school I went to. Do I care if this is http or https?" The downsides of forcing https are minimal and it eliminates human error from the security equation.
But I have no idea what the benefit [of HTTPS with a null cipher] would be over just sending the content over HTTPs [with a nontrivial cipher].
In theory, a protocol guaranteeing integrity and authentication but not confidentiality would allow intermediate caching on the client's private network but allow devices to detect malicious intermediate modification. This at least would prevent having to send 25 copies of an article over a slow, metered link to a sub-Saharan classroom, one to each of 25 students.
It was some "HSTS" (Hyper Sensitive Trust bullShit) thing
Did you send mail to the site's administrator?
Please explain to me how you would encode Korean or Japanese in an 8-bit encoding.
Codepage! Like in the old days. You use yours, I use mine.
All the characters of Chinese or Japanese do not fit in one codepage. (Shift-JIS is not 8-bit.) Nor do all Korean syllables; would you instead decompose each character into its jamo?
You use yours, I use mine.
If they mismatch, there is garbage. If instead you standardize a way to switch codepages within a document, you have reinvented Standard Compression Scheme for Unicode (SCSU). The web abandoned SCSU because cross-site scripting is easier in SCSU than in UTF-8.
That's a softball. Digital signatures.
Which raises the question of how to transmit cacheably signed documents to a web browser in a way that the browser understands. If there were a way to deliver signed static cleartext to a browser, there wouldn't be quite as much need for a "corporate MITM" feature.
Have you _used_ the modern internet in the past five years? A _ton_ of content is dynamically generated.
And a lot is not, especially things like images, style sheets, and scripts, the kind of things for which sites use an Expires: date in the far future. Sometimes, the front page is dynamic, but the article pages need not be. But often, the only reason that a dynamically generated document can't be cached for days at a time is a desire to stalk viewers in order to deliver behaviorally targeted advertisements.
On-site caches are far less useful than they were at the turn of the century.
I agree with you with respect to urban areas of developed countries, but not so much in remote, rural areas and/or less-developed countries.
CDNs and big content providers are _more_ than happy to install content caches on site if your site is large enough.
A single school produces classroom quantities (20-30) of views for an article within an hour, but it's probably not large enough.
" there is little benefit to https for many sites, which simply present publicly available information. "
The benefit is for users, not sites.
Snoopers can still collect metedata about what connections you're making (and what DNS queries you made. HINT!), but they can't see the content of what you're accessing.
One of the lessons about crypto is that if you only encrypt the sensitive stuff then anything encrypted is a big red "kick me" flag for a snooper and the're likely to keep the raw packets around until they can decode it. If you encrypt everything including your shoppings lists, then they may spend a long time cracking your shopping list.
In other words, encrypting everything is a little like stegenography, The sensitive stuff is just as visible as the non-sensitive stuff, but you have to know how to look at either, else it just looks like a gif of Claudia Schiffer (and for those who don't get the reference, take a closer look at the 1990s usenet postings of Ms Schiffer's pictures)
" Can't remember the last time my ISP actually cached a website. "
In my ISP days, we were only getting a 20% hit rate in the 1990s and eventually gave it up as not worthwhile. Ditto when operating corp transparent proxies. The costs of operation were higher than the savings
ISPs which continued doing it tended to do so specifically so they COULD act as MiTM
"On mobile devices the effect is componded"
Transparent proxies at the mobile company's gateways make little-to-no difference. The bottleneck is INSIDE the mobile network (specifically at the last hop to the cellular site and the link from base station to mobile) and it doesn't matter if what's being moved is cached data or fresh off 't web.
What you're stating is an argument for caching on the device. Running proxies at every single edge station is a nightmarish scenario which would provide very limited benefit.
If abortionhelp.example is the only host on that IP, then none of this matters
Yes it does. Every modern browser sends the hostname as part of the TLS ClientHello in order to support name-based virtual hosting. The last notable browsers that didn't support Server Name Indication (SNI) were Internet Explorer for Windows XP and Android Browser for Android 2.x, and security updates for IE/XP ended nearly four years ago.
As you said, TLS doesn't stop anyone from knowing which site you are accessing. Therefore encrypting the non-sensitive sites you read in no way obscures your connection to sensitive sites.
I understand that thinking behind that. I've also seen it backfire over and over. The core Wordpress team suffered from that for years. They'd kinda sorta hide stuff that wasn't really security sensitive, except well maybe. For example user IDs were hidden, except when they aren't. Some people saw that user IDs were not displayed and treated them as secrets, as secure, or secure-ish. But they were readily visible in Wordpress forums. Several different Wordpress security vulnerabilities were caused by failing to be clear about what is secret, what is secured, and what is not.
We've all seen the mess caused by treating social security numbers as if they were secret authenticators, while also handing them out to many organizations to treat as identifiers. Based on these types of experiences, my rule is to be very clear about what's secure and what's not. I don't waste time and energy making something seem secure of it isn't secure or doesn't need to be. I'm very clear about exactly what needs to be secure and what elements of security it has.
> So... your argument is that it's so important that they be able to scan incoming traffic for malware that HTTPS shouldn't be used... but they shouldn't be able to scan HTTPS traffic for malware?
My argument is that intelligent defense requires considering different threats, the likelihood of each threat and the damage it cause. When I'm reading instructables, perhaps getting ideas for how to mount the camera on my quadcopter, the main threat is malware on the page. Sending that through the ASA is a good idea. When I'm logging into my Scottrade account, the primary risk is exposing exposing Scottrade credentials. End to end encryption is the best defense.
> I work with many other people who collectively have millenia of experience... and all agree that the security of the web is best-served by 100% TLS penetration.
You might be surprised. If you *asked* them, rather than assuming that everyone must always agree with you, you might find that most of them recognize the value of considering which threats apply in a given situation, involving a given asset, and applying defenses which best mitigate the relevant threats. Doing any one thing all the time, treating everything exactly the same, might not be as popular as you think it is.
Yes and no at the same time. A lot of sites are moving to certificate pinning because of this exact problem, but because of malicious actors.
With certificate pinning, anyone, including corporate environments, cannot MITM a site successfully irrelevant of the CA setup. Sure, some of the content may load depending on how it is configured, but you ultimately cant use the site. We pin all our public services for this exact reason because we dont know what ISP ABC/Stateactor XYZ is doing to our customers traffic which is highly sensitive.
Good old gmail has pinning from memory.
In this case, it does mean that we cannot MITM our staff access to those sites at the proxy level meaning we are one security defense down in that respect. Sure the endpoint still has security and _should_ pick it up, but security is about layers.
> A single school produces classroom quantities (20-30) of views for an article within an hour...
Which makes me wonder why you seem to think that it'd be useful to set up an _automatic_ on-site cache at a place like that.
> Which raises the question of how to transmit...
Stop hinting at things you already know. Anyone who knows anything about TLS also knows about digital signatures and checkhashes. There's even a year-old W3C spec called Subresource Integrity that addresses this problem.
Elsewhere in this thread, a guy who worked at an ISP in the 90's mentions that their ISP-level cache saw hit rates of only 20%. Truth is, most Internet caches are going to see _abysmal_ hit rates unless the population of users hits a very small subset of the Internet.
> In this case, [cert pinning means] that we cannot MITM our staff access to those sites at the proxy level...
BZZT. Wrong. Check this out:
http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-
The money paragraphs:
"Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.
We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate — that is, the client is already under the control of the person who controls the proxy (e.g. the enterprise’s IT administrator). If the client does not trust the private trust anchor, the proxy’s attempt to mediate the connection will fail as it should."
> When I'm logging into my Scottrade account, the primary risk is exposing exposing Scottrade credentials. End to end encryption is the best defense.
N... no.
If you're _actually_ concerned about credential exposure, then you use a tamper-evident hardware token for multi-factor login.
Hell, I'd be _far_ more worried about malware on Scottrade than on Instructables. Scottrade is a _far_ larger and _far_ more valuable target and the Masters Of The Universe have proven time and again that they truly DGAF about infosec.
If you're _actually_ concerned about HTTP-delivered malware, you _must_ scan _all_ HTTP traffic.
Anyone who knows anything about TLS also knows about digital signatures and checkhashes.
What browsers will accept a cipher suite containing only key exchange and HMAC (the "digital signatures and checkhashes") without bulk encryption?
There's even a year-old W3C spec called Subresource Integrity that addresses this problem.
Even if it works for images, style sheets, and scripts, it won't work for the HTML document itself because it's subresource integrity, not mainresource integrity. In addition, Mozilla's page about SRI doesn't mention the ability for an HTTPS document to use SRI to verify cleartext subresources in order to avoid restrictions imposed by browsers' Mixed Content and Secure Contexts policies. Nor does W3C's spec, though section 5.1 "Non-secure contexts remain non-secure" thereof (wisely) suggests not trusting SRI when the main document is cleartext.
... it make the web no more secure because web masters and web hosts completely suck at security. How many more multi-million user data breaches do you need to see?
Nobody said users should decide. People running web sites decide whether to use TLS or not, and if so which direction(s) the certificate authentication should go. If you have a login or payment form hosted on the site, it should probably use TLS
I had a web site that provided information for webmasters of small sites, tutorials and such, as well as product reviews. There was no login, no payment form, no PII of any kind. There is little reason to use TLS on such a site. TLS does provide a degree of integrity, but there are tradeoffs for that, a cost in security.
See subject: HTTPs/SSL's always getting broken into inevitably & slows you down for what? Penetratable 'security'?? No thanks!
Your point on it being 'championed' by spying companies is solid.
Additionally onto your list of securing things online?
* STOP GoDaddy (or other hosting providers) from allowing UNLIMITED SUBDOMAINS beneath $1 domain registrations!
It's cancer & JUST ASKING FOR MALWARE MAKERS + SPAMMAILERS TO "GO WILD" w/ that many subdomains for no added cost!
(Cost's a big part of what holds them back in DGA botnets & also so is disksize (which hasn't grown enough to hold say, 5 billion subdomains generated)).
APK
P.S.=> Good points - especially pointing out it's Google behind this HTTPs effort - what ticks me off is that IF you incorporate SSL into your programs via libs? You will probably have to recompile with changed function call parameters BECAUSE SSL is always being CHANGED or BROKEN! apk
You don't understand. You might want to work on that.
Short answer, governments and hackers destroyed the trust easily found on the early internet.
That's a logical thing to think. Not quite right though.
The reason you couldn't have more than ssl site on an IP was that the server has to include its certificate in the Server Ello, the first message sent by the server. The client has to validate the certificate (and therefore the server) before it shares encryption keys with some otherwise unknown actor out on the internet somewhere. The certificate has to be validated WAY before the Host: header is sent, so the server had no way of choosing between different certificates for different sites on the same IP.
About ten or twelve years ago we introduced Server Name Indication to solve that problem. With SNI, in the very first message of the TLS handshake (ClientHello) the client says "Hello I'd like to speak to eBay.com, and I can use the following encryption algorithms". That's the FIRST message sent, way before encryption is set up. The server might not even host the site anymore and the client is still going to send out, in plain text "I'm connecting to Lolitas.com", because it can't even know that's the right server with first announcing which name it's looking for. The encrypted session starts several messages later, after the server knows which site's key to use for encryption, and the client has validated that the cert belongs to that site.
Suppose you could somehow make the ClientHello invisible, so nobody can see the client announcing which site name it is connecting to. Eavesdroppers could STILL see the name because it's in the TLS certificate! You have to send the certificate before you can start an encrypted session based on that cert, so there's no way to hide the name even if you changed the TLS protocol, without completely redesigning it to be a completely different protocol altogether.
"That's the FIRST message sent, way before encryption is set up"
Looks like it's time to somehow wrap that handshake before moving onto the "I'd like to talk to XYZ site" and adopting that one's certificate.
I'm less worried about governments most of the time and more about companies - particularly advertisers.
Big Brother is watching YOU, so he can work out what to sell at you.
> Looks like it's time to somehow wrap that handshake before moving onto the "I'd like to talk to XYZ site" and adopting that one's certificate.
I guess I wasn't clear about that point in my post. The thing that selects which certificate (which site) IS a man-in-the-middle. So you can't do that while protecting from man-in-the-middle.
Perhaps the best you can do is through some other, out-of-band secure channel, publish a list which men in the middle are allowed. So you'd have a DNS record (DNSSEC signed) saying "traffic to PayPal.com may be intercepted by webserver47474.rackspace.com".
Note DNSSEC doesn't hide your DNS requests, it only authenticates the replies.