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...

For personal sites it doesn't matter, your Google rank will barely be affected, if at all. For anything else the bar is so low it's probably zero effort as you wanted the CDN anyway or need at least some secure pages for log in etc.

Because my little brother, guy sitting next to me at Starbucks, my ISP, and government don't need to have a clear text view of everything, or anything, I'm doing. It's not that I'm doing anything wrong... It's that it's none of their fucking business.

Maybe they don't right now, or in a year, or 10 years, or maybe never.But maybe, at some point, whoever is in control of that data decides they want to smear you by cherry picking the sites you've visited. Or maybe they use it to build a court case against you. Or maybe they use it to watch out for "dissidents" or those who won't submit to a dictatorship.

Would you want to live in a society where the gov knows exactly where you've gone and what you've done both historically and in real time? The US is dangerously close to this stage already.

HTTPS makes it just a little harder for them to do this. Does it solve every security and privacy problem? No, it sure doesn't, but it's a step in the right direction.

A democracy dies when it's people become too complacent to demand their rights be recognized.

Until you speak out politically. Until you're photographed at a protest. Until you're a nuisance to those in power. Then you may find that you want the government to not have low-effort ways to attack you.

Remember, there's no telling what topics that are innocuous today will become reputation-wrecking or outright illegal in 20 or 40 years, and the government has a habit of keeping everything in case it might be useful one day.

Never assume that because the government has no interest in you today, that because you're not doing anything sketchy today that today's actions can't be used against you. And never assume that the government isn't recording everything.

Anyhow, https is nearly free - why shouldn't it be used everywhere all the time? Low cost for potentially massive benefit.

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.

>unning your own CA and installing its root on all devices on your network. The latter is difficult on many platforms.

So if you want security don't buy shitty devices that don't allow you to install certs from your own CA. You are on this strange rant about SSL on the local network. Just fucking ignore the error on your local network.

How is adding HTTPS making things easier to track? It makes it harder not easier.

Without HTTPS anyone between your web browser and the web server at Megofan can inject HTML, including JavaScript, into the HTTP connection and cause your browser to execute the code they want it to.

The benefit of HTTPS is not JUST securing the content of the message, it's adding integrity to the message. The only way it can be broken is an SSL proxy attack using a stolen Certificate Authority that your browser also trusts. How

"Without HTTPS anyone between your web browser and the web server at Megofan can inject HTML, including JavaScript, into the HTTP connection and cause your browser to execute the code they want it to."

Lest anyone scoff at this, it's already been happening. A lot of ISPs force all port 80 traffic via transparent proxies and some started doing this kind of man-in-the-middle attack as far back as the late 1990s.

No sign in, no tracking, just pics and text about characters, weapons, levels, etc...now how EXACTLY is forcing all those sites to go to HTTPS gonna make my life any safer?

So you're researching weapons, eh? On the list with you!

Do you somehow not understand what HTTPS is? It in no way aids anyone in tracking you (and the days of it being expensive are long gone). It does make it cost-prohibitive for the government to track the contents of everyone's internet activity. It only people doing "interesting" things use encryption, well, on the list with them!

HTTPS ensures that visitors to your site will see the pages exactly as delivered by the site, whereas HTTP allows any intermediate ISP/Wifi provider to change the content and/or insert their own adverts. It's also easy for malicious entities to insert hidden bits of javascript to do whatever they want to.

If the content is signed, the signature will either match of it won't. So the OPs proposal would work. But I have no idea what the benefit would be over just sending the content over HTTPs. CPU cycles are so cheap that it worth the effort to implement this. Plus it would still make it harder for the user to determine whether or not the security was acceptable for the intended action.
The first few posts in this thread made me question whether HTTPs everywhere was a good idea. They made their points w

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.

Is the clear text view any less revealing than the DNS lookups or the initial requests (which I assume have to be specify in clear-text to start the exchange?) I get that some subpages may be sensitive, but I'd imagine that's "personal data" that GP was referrring to.

The ClientHello shows only the domain name, not the particular path within the domain. For example, it shows only that you visited WebMD, but the identity of particular document you are viewing is encrypted. All an eavesdropper can do is traffic analysis on approximate document lengths, and there are mitigations for even that.

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?

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.

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.

So you've got 20 years of professional experience yet don't recognize the dangers of MITM attacks from non-HTTPS pages?

For public sites where you don't log in, I think https is a net reduction of security.

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.

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

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.

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.

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 li

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?

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.

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 rea

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.

In my professional judgement, there is little benefit to https for many sites, which simply present publicly available information.

Allow me to entertain the opposite argument:

Imagine trying to view wikipedia entry for homosexuality in Iran.
Imagine trying to view wikipedia entry for abortion from a catholic school library computer.
Imagine trying to view wikipedia entry for treatment of hemorrhoids at work computer.
Imagine trying to view wikipedia entry for Navalny in Russia.
Imagine trying to view wikipedia entry for Tibetian Buddhism in China.
Imagine trying to view wikipedia entry for teen pregnancy from home computer.
Imagine trying to view any of the above privately without your ISP finding out and selling the details to the next highest bidder.
There are a million reasons why your web browsing is NONE OF SOMEONE ELSE'S BUSINESS.

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 mo

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 wi

. The question is "which is a more likely threat, a mitm or a hacked WordPress?"

That question is irrelevant. There's a simple way to eliminate the former threat, so it should be eliminated.

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.

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? Please make up your mind.

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.

I didn't directly address your implied argument from authority and instead just explained why you were wrong. If you want to continue invoking that fallacious argument, though, I'll

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.

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.

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.

If you work in security, I really hope I never have to deal with any of the companies you've worked for.

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 res

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.

" 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 t

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.

Without HTTPS, you are the mercy of anybody between you and what you think is the website you're browsing. It doesn't just obscure data transit, it provides verification to varying levels that you are viewing the site you think you are.

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.

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 atta

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 reloade

One motivation is to make it more difficult to distinguish important and sensitive information from wasted bandwidth, which makes it harder to censor. Of course, since the destination is known at the IP layer with HTTPS, that's of somewhat limited value.

The Snowden news showed the security services got to collect it all along the different networks globally.
With more HTTPS that easy plain text collection should have got more difficult.
It was felt collection would have to be at the origin or destination with HTTPS.
No more free way to see a search term, the context of using a HTTP site globally.

HTTPS prevents a malicious ISP/WiFI provider from intercepting all HTTP traffic and changing selected parts. e.g. inserting their own adverts instead of the original adverts or even inserting ads where there were no ads. It's also easy for someone to change the content of HTTP pages.

The path and query string of the specific document you are visiting is itself private information. If, for example, it's a document on WebMD about a particular medical condition, your interest in the condition can be used against you or your family.

HTTPS also provides authentication that an intermediate actor didn't tamper with the connection. Comcast is known to inject advertising scripts into HTML documents delivered through cleartext HTTP.

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) [wikipedia.org]. The web abandoned SCSU because cross-site scripting is easier in SCSU than in UTF-8.

It's like they know you are visiting a brothel, just not what you are doing in there.

Also, DNS is still unencrypted [...]

There are many-many attacks that don't require complete knowledge of the contents of web traffic to work

The things that are not encrypted are the DNS queries and the IP address of the endpoints.

Grandparent's point is that "There are many-many attacks that" need only "the DNS queries and the IP address of the endpoints" "to work." If the authoritarian government knows you're visiting a URL that begins with https://abortionhelp.example/, you're already in trouble.

in oppressive countries the government might want to know everyone who visits a particular page (organising a protest) on a website with thousands of pages, but not care about the other pages.

If the protest is organized on a website dedicated to a particular cause, such as https://righttochoice.example/events/2018/, the authoritarian government can already see the righttochoice.example hostname through inspection of both DNS and ClientHello.

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.

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.

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.

Actually part of the SSL standard does allow for client side certificates and TLS has the same functionality. It is rarely implemented for a variety of reasons which all come down to "because it is hard".

There are client certificates and they've been supported by all major browsers for well over a decade. There's also a standard for generating them from JavaScript, which is less well supported, but is quite a nice way of doing client authentication (after first login, create a client cert and register it for use on that site and you never need to transmit the password from that computer to the server again).

That said, the most common implementation is to have a different client cert for each service, so i

Sounds like suicide. Normal people will never figure out managing certs over all their devices, for example. And talk about making it hard for users to discover your services. Aside from things like email, most Google stuff works without login, even over Tor and without JavaScript.

indeed, I don't appreciate this agenda driven bullshit for what it totally unnecessary for many websites. Someone's going to snoop my relatives looks at family pictures on my website? I have to use a web stack that that shitty 90 day free cert ware they're pushing supports. and browsers are on board with your stupidity? fuck you, EFF.

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.

There is no need for you, the operator, to be “certified”. The TLS certificate installed on your server merely increases the odds (for your users) that the machine serving the content (your server) is really the one that they expected (rather than a server operated by a malicious operator) and that the content received is really the content that was sent by that machine (rather than fake content fraudulently injected during transit by a malicious actor). It’s rather sensible to promote sec

[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

I'm pretty sure they go by their acronym "EFF" alone (kinda like "KFC" and "SAT"), which doesn't stand for anything any more---which is quite fitting, because the organization itself doesn't stand for anything any more.

Because they actually know how certs work and you clearly don't. The cert just guaranteed that the site the user is trying to connect to is in fact the site they are connecting to, and they are free. There is no conspiracy, just security.

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.

The nice thing about Let's Encrypt is that they are not just a CA, they are also a well-specified protocol (with multiple implementations) for automatically deploying certs. Lots of low-value sites are secured by Let's Encrypt, but once you've got the infrastructure in place then it's relatively easy to switch to any other CA that implements the ACME protocol.

I've seen a couple advertising ACME support. You can use ACME with client authentication, so it's compatible with EV: as long as you do the validation out of band and provide the credentials, you can then still use ACME for signing and deploying the certs.