Hacker News Reader

Hacker News

Comment by mholt | Hacker News Reader

Parent Full thread

mholt

> developers who just want their software to work.

Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with.

> they either don't know or don't care about all the effort and pain they're creating

You have not been paying attention to the hundreds of tools available to make HTTPS painless.

> until someone at Big G decided they weren't.

And Mozilla. And countless research papers. And real-world attacks that are reported over and over again. The fact is that the global Web has become hostile, regardless of your prejudice against Google's Web security teams.

> In many cases the cost of the security is not worth it.

The problem is that it's not YOUR security, it's other people's. If websites don't implement HTTPS, it's the users of the Web who pay the price. It's their privacy being deprived. And the website becomes easy to impersonate and manipulate, increasing the liability of having a website. HTTP is bad news all around.

View on HN

What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS defeats this and makes it uncachable.

I hardly ever see people talk about this use case and how to solve it with https everywhere. AND it's super widely used: e.g. debian repositories.

Clients for this aren’t web browsers. Making browsers warn about them doesn’t break anything.

HTTPS doesn't make it uncacheable - you can still mirror an HTTPS repository with another HTTPS repository (with its own domain name and certificate), and preserve the PGP signatures inside the repository. apt works fine with exactly this model: you use HTTPS for transport-layer protection and GPG for the existing things Debian's security model was already good at. The Debian repository is behind HTTPS at https://deb.debian.org - in existing Debian releases you may need to install apt-transport-https, and then just set your sources.list to

    deb https://deb.debian.org/debian stable main

HTTPS cannot be used as a replacement for PGP in this scenario, but that's the wrong way to see HTTPS. It doesn't provide purpose-built security for people who have custom threat models and need to build security infrastructure anyway (e.g., Debian verifies PGP signatures on sets of packages uploaded by developers, and then builds those packages and puts them into signed archives). HTTPS is baseline security - it's the security that every web connection should just have. It's not surprising that some specific use case like Debian repositories needs more-than-baseline security.

And because HTTPS is nothing more than baseline security, it's possible to automate it with things like Let's Encrypt and not add any more checking beyond current control of DNS or HTTP traffic to the domain.

(Another confusion along these lines is assuming HTTPS is useful as an assertion that a site isn't malware. It asserts no such thing, only that the site is who it claims to be and network attackers are not present. If I am the person who registered paypal-online-secure-totes-legit.com, I should be able to get a cert for it, because HTTPS attests to nothing else.)

I'm not talking about a mirror, which has a different domain name. I'm talking about a transparent cache like squid. This will mean I don't have to change the OS images that I might not even control in order to get traffic savings, whereas under your model I would have to, which again, may not even be feasible.

> What about hosting HTTP content because you verify GPG signatures upon download

If you're doing this, then you've made your own HTTP client so you can do whatever you want.

"HTTPS Everywhere" is a web browser thing.

So it's just bad naming. Everywhere to me implies everywhere, not just everywhere in the browser. Regardless, it looks like there are still people confused about it like me discussing in this thread, tho.

There are a variety of attacks against GPG-signed repositories - an article [1] by Joe Damato explains them, and that all can be trivially mitigated by serving the repositories with TLS.

[1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...

On HN: https://news.ycombinator.com/item?id=16432435

I'm actually surprised debian repos are still HTTP.

Don't get me wrong GPG signatures with pinned public key is a lot better than trust TLS of a random mirror.

But isn't it nice to have two layers, the two key systems are independent and orthogonal that seems like a solid win.

Need I remind of Heartbleed (openssl) or the very debian specific gpg key derivation bug years ago.

There will always be bugs, we can only hope they aren't exposed concurrently :)

That, and the way gpg is used for apt provides no confidentiality at all, just authenticity & integrity. Someone who can see the traffic will still know which packages you've downloaded.

Indeed. The same is also true for repositories, served via SSL.

Majority of HTTPS traffic is sniffable and largely non-confidential, unless you pad every file and web-request to several gigabytes in size.

Does your website use gzip? Good, now padding won't help you either, — unless it is way bigger than original content. Oh, and make sure, that you defend against timing attacks as well! Passive sniffers totally won't identify specific webpage based on it's generation time, will they?!

As for authenticity… Surely, you are going to use certificate pinning (which is already removed from Google Chrome for political reasons). And personally sue certificate issuer, when Certificate Transparency logs reveal, that one of Let's Encrypt employees sold a bunch of private keys to third parties. Of course, that won't protect authenticity, but at least, you will avenge it, right?

SSL-protected HTTP is just barely ahead of unencrypted HTTP in terms of transport-level security. But it is being sold as golden bullet, and people like you are the ones to blame.

TLS is getting better and there is a LOT of momentum to this.

I bet the SNI issues will eventually be fixed too.

And yes, with momentum behind certificate transparency, it could definitely hold CAs to the fire :)

TLS is no silver bullet, but it's a good base layer to always add.

Having two independent system while destroying traffic savings from a transparent caching system seems like a bad trade off to me.

Consider you're a cloud provider running customer images. If everyone downloaded the same package via https over and over again, the incurred network utilization would be massive (to both you and the debian repository in general) compared to if everyone used http and verified via GPG, all from your transparent squid cache you setup on the local network.

I fear the trust issues with generic HTTP caching makes it infeasible.

It would probably be better to use a distributed system design for this.. BitTorrent or who knows ipfs maybe..

> What about hosting HTTP content because you verify GPG signatures upon download?

Because the rest of the content is not verified?????? That's the whole point of HTTPS????????

I didn't downvote this and this is a valid misunderstanding.

The whole point of having GPG is that you (as the distributor/debian repo/whatever) have already somehow distributed the public key to your clients (customers/debian installations/whatever). Having HTTPS is redundant as it is presumed that initial key distribution was done securely.

Those who you trust with your internet browsing is usually also those who you trust with HTTPS certificates. Eg. Your browser, your operating system, your ISP, et.al are still able to spy on you unless the site uses certificate pinning, which is unfortunately not feasible with Letsencrypt due to certs only lasting 3 months.

"It's their privacy being deprived."

I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow.

Will these "advances" benefit users more than they benefit the companies serving ads, collecting user data and "overseeing the www" generally? Is there a trade-off?

To users, will protecting traffic from manipulation be viewed as a step forward if as a result they only see an increase in ads and data collection?

Even more, perhaps they will have limited ability to "see" the increase in data collection if they have effectively no control over the encryption process. (e.g., too complex, inability to monitor the data being sent, etc.)

I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow.

We're talking only by HTTPS. Adding HTTP/2 is just mudding the conversation.

Care to give any argument on how does adding a TLS layer over the exact same protocol (HTTP/1.1) will be used to do that?

/I wonder/s/HTTPS/TLS/

> Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with.

Except most big orgs now employ MitM tools like BlueCoat to sniff SSL connections too.

> You have not been paying attention to the hundreds of tools available to make HTTPS painless.

I have, and they don't. They make it easier, but you know what's truly painless? Hosting an html file over HTTP. What happens when Let's Encrypt is down for an extended period? What happens when someone compromises them?

> And real-world attacks that are reported over and over again.

Care to link to a few?

> The problem is that it's not YOUR security, it's other people's.

Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users?

A lot of ISPs, some huge like the "XfinityWifi" SSID, routinely inject their own javascript in HTTP pages. Some even take no care to namespace their javascript and wreck a party on your window globals, too.

This could be solved without HTTPS. People choose not to for ideological reasons.

How would you solve it without HTTPS?

By signing it.

"Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this.

One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser would verify the checksum before rendering the page. However, if you can modify the payload, you could also modify this header.

The next method is to use a cryptographic signature. By signing the checksum, you can use a public key to verify the checksum was created by the origin. However, if the first transfer of the public key is not secure, an attacker can replace it with their own public key, making it impossible to tell if this is the origin's content.

One way to solve this is with PKI. If a client maintains a list of trusted certificate authorities, it can verify signed messages in a way that an attacker cannot circumvent by injection. Now we can verify not only that the payload has not changed, but also who signed it (which key, or certificate).

Note that this does not require a secure transport tunnel. Your payload is in the clear, and thus can be easily cached and proxied by any intermediary, but they can not change your data. So why don't we do this?

Simple: the people who have the most influence over these technologies do not want plaintext data on the network, even if its authenticity and integrity are assured. They value privacy over all else, to the point of detriment to users and organizations who would otherwise benefit from such capability.

And what happens when the content changes? Cacheability is not always a good thing. Your solution is vulnerable to replay attacks. You could be seeing an outdated version of a resource without knowing it. This is only acceptable for truly static content, which is becoming increasingly rare on the web.

This content should not change, or change very rarely. A bulk of the data on the web is media files and static resources. Until browsers started locking down 3rd party requests, handling these over HTTP was standard. Obviously it was a security problem, but it wouldn't have been with this alternate method.

However, it's not that hard to avoid replay after cache expires. HTTP sends the Date of the response along with Cache-Control instructions. If the headers are also signed they can also be verified by a client. If the client sees that the response has clearly expired, it can discard the document. As a more dirty hack it can also retry it with a new unique query string, or provide it as an HTTP header and token which must be returned in the response.

Sounds like you just reinvented HTTPS with a null encryption cipher. I don't see how this makes anything easier or better.

I would love if null encryption ciphers actually worked in real life, but they don't (for the same reason why plaintext HTTP/2 does not — everyone disabled them under political pressure).

By the way, — signing is not equal to "null encryption". Signing can be done in advance, once. Signed data can be served via sendfile(). It does not incur CPU overhead on each request. Signing does not require communicating with untrusted parties using vulnerable SSL libraries (which can compromise your entire server).

As we speak, your SSL connection may be tampered with. Someone may be using a heardbleed-like vulnerability in the server or your browser (or both). You won't know about this, because you aren't personally auditing the binary data, that goes in and out of wire… Humorously enough, one needs to actively MITM and record connections to audit them. Plaintext data is easier to audit and reason about.

And how do you sign these requests? How do you get browsers to trust the signature? Oh, well, we already have a similar solution that also protects the entire connection from spying... it's called HTTPS.

> Oh, so you know better than me what kind of content is on my site?

The content of your site is irrelevant. We do know that your lack of concern for your user's safety is a problem though.

I also wish that managing certs was better, but until then, passing negative externalities to your users is pretty sleazy.

> Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users?

Without TLS how do YOU know that the user is receiving your static resume. Any MitM can tamper with the connection and replace your content with something malicious. With properly configured TLS that's simply not possible (with the exception you describe in corporate settings where BlueCoat's cert has to be added to the machine's trust store in order for that sniffing to be possible). Hopefully in the future even that wont be possible.

And web servers can even detect TLS MITM: https://caddyserver.com/docs/mitm-detection

It's like one apt package and one cronjob away. I think some acme clients even do the Cron handling for you. So, like one command. There is a really great acme client written in bash which is incredibly painless to set up.

Literally in the time you've spent thinking about and composing your reply you could have implemented free, secure TLS for your users.

It's not that easy if you don't want to run public http server. I had to write acme client myself because I didn't find a single one simple enough. I spent weeks doing that, comparing to 5 minutes issuing 3-year certificate from wosign when it was a thing. I hate that Google destroyed every free ssl certificate issuer and pushed their child to further dominate the world.

>wosign

Are you name dropping wosign just to be obtuse? They were untrusted because they were untrustworthy, not because Google just doesn't like them. https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...

I don't trust any US company, so it's not any more untrustworthy for me than DigiCert, for example. I'm dropping its name because they were offering free 3-year certificates and it was the best TLS experience I've ever had.

There's a lot of countries I don't trust to keep sensitive data in. But my point is that Wosign was provably untrustworthy, rather than speculation on government interference in other CAs. I saw from your Github that you live in Kazakhstan, I would remind you the government is less than trustworthy as well[0] in regards to digital privacy.

[0]: http://www.slate.com/blogs/future_tense/2015/12/14/kazakhsta...

I doubt, that any government is inherently more trustworthy than any other.

It just coincidentally happens, that US controls 100% of root CAs and Kazakhstan (most likely) controls 0. So the later needs more audacious measures, while former can just issue a gag order to Symantec (or whoever is currently active in market).

CA system is inherently vulnerable to government intervention. There is no point in considering defense against state agents in HTTPS vulnerability model. It is busted by default.

Maybe not 100%. Bermuda has a root CA: QuoVadis Global.

https://github.com/Neilpang/acme.sh does exactly what you want.

Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users?

Absolutely yes. Without that layer of security, anyone looking at your resume could either be served something that's not your resume (to your professional detriment) or more likely, the malware-of-the-week. (Also to your professional detriment).

Do you care for the general safety of web users? Secure your shit. If not for them, for your own career.

So I've heard this argument countless times, and it completely makes sense from a theoretical perspective. Yes, it's very possible for MitM to happen, and that would cause one of the two scenarios you described.

But how likely is it to actually happen? For the former, someone would need to target both you and specifically the person who you think will view your resume, and that's, let's be honest, completely unlikely for most people. The second case I can see happening more in theory as it's less discriminating, but does it actually happen often enough in real life to the point where it's a real concern?

FWIW, I have HTTPS on all my websites (because, as everyone mentioned already, it's dead simple to add) including personal and internal, but I still question the probability of an attack on any of them actually happening.

I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.

Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening.

Basically, I see it this way:

- You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause the user to actually notice because then their ass is going to be on the line when it's exposed that Comcast installed viruses on millions of computers or stole everyone's data.

- Or you can be MitMed specifically, which will cause professional detriment, but would require someone to specifically target you and your users. And I don't see this as that likely for the average Joe.

Really, what I would like to know is: How realistic is it that I, as a site owner, will be adversely affected by the MitM that could theoretically happen to my users on HTTP?

As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it.

Consider the websites you view every day.. most of them are probably HTTPS by now.

It's the wild west, basically. Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can screw with it, why even take that risk when the alternative is so easy?

> As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it.

I've already covered the general case above. Anyone in a position to intercept HTTP communications like that (into every unencrypted connection) is in a position where if they intercept and do enough to materially harm me or my users through their act, then they will likely be discovered and the world will turn against them. They have far more to lose than to gain by doing something actively malicious that can be perceived by the user. So I don't realistically see it happening.

> Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can screw with it, why even take that risk when the alternative is so easy?

I already said I use HTTPS, so your advice isn't really warranted. I also specifically asked how likely it is, so you can't just "regardless" it away. I get that there's a theoretical risk, and I've already addressed it. But as a thought experiment, it is helpful to know how realistic the threat actually is. So far, I haven't really been convinced it actually is anything other than a theoretical attack vector.

You are making it sound like "injecting random garbage into HTTP" is some new hotness. It have been done since forever. By the way, — email still works that way. But Google and a couple of other corporations would not like you to trample their email-harvesting business, so there is disproportionately less FUD and fear-mongering being spread around email connections.

Internet providers have been injecting ads into websites for years. Hackers and government have been doing same to executables and other forms of unprotected payload.

Hashes, cryptographic signatures, executables signing, Content-Security-Policy, sub-resource integrity — numerous specifications have been created to address integrity of web. There is no indication, that those specifications failed (and in fact, they remain useful even after widespread adoption of HTTPS).

For the most part, integrity of modern web communication is already controlled even in absence of SSL. The only missing piece is somehow verifying integrity of initial HTML page.

> Care to link a few?

From Friday, in which Turkey takes advantage of HTTP downloads to install spyware on YPG computers: https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlo...

From a couple months ago, where Comcast injects JavaScript into HTTP connections: http://forums.xfinity.com/t5/Customer-Service/Are-you-aware/...

Reply on news.ycombinator.com