3 ms·
This argument boils down to two things: One side: We want performance / caching! Other side: We want security! Both sides sometimes argue disingenuously. It'
by 3pt14159 8y ago
This argument boils down to two things:
One side: We want performance / caching!
Other side: We want security!
Both sides sometimes argue disingenuously. It's true that caching is harder with layered HTTPS and that performance is worse. It's also true that layering encryption is more secure. (It's what the NSA and CIA do. You smarter than them?)
Personally, I'd default to security because I'm a software dev. If I were a little kid on a shoddy, expensive third world internet connection I'd probably prefer the opposite.
I just wish it were up to me.
- eloisant 8y agoNot in this case, just read the tl;dr in the article (you don't even need to read the whole article).
- buster 8y agoExcept that this page argues, that you are not increasing security in this case.
- zeroimpl 8y agoBut it does, because HTTPS can ensure you always get up to date data. They have a solution involving timestamps for HTTP, but that is still clearly less secure than the guarantee from HTTPS.
- shittyadmin 8y agoThis page is wrong, for example they claim there's no privacy increase here but quite clearly there's a huge difference between an attacker being able to tell "you're downloading updates" and an attacker being able to tell "you're downloading version X.Y of Z package" - worse, that information could actually later be used to attack you based on the fact that the attacker now knows what version to find vulnerabilities in, including non-exposed client software for email, documents, browsers, etc. It's a relatively insignificant security benefit for most, but could prove an important one for those who targeted attacks are used against.
- j16sdiz 8y agoExpect the attacker can tell the package version in https. Read the footnote in the article.
- shittyadmin 8y agoThey're speculating that you can do this using size of the full connection - there's truth to that, but under HTTPS padding will occur causing a round up to the block size of the cipher - meaning that there's a higher chance of overlap in package sizes. It might actually become quite difficult to do such analysis, especially if multiple requests were made for packages at once in a connection that's kept open. You won't get direct file sizes either, you'd have to perform analysis for overhead and such - in any case it's significantly less trivial than an HTTP request logger.
- Rapzid 8y agoEven then one is guessing and the other is establishing a fact. That part of the argument didn't sit right with me and I can't imagine somebody in Info Sec or Legal conflating the two..
- oliwarner 8y agoI think it's important to reiterate that HTTPS only adds network privacy about what you download. The signing of repos and their packages means they're guaranteed to be a pure copy of what's on the server. That same mechanism means you can easily make trusted mirrors on untrusted hosting.
- yeaaaaaaaah 8y agoExcept the signing key was also downloaded over plain HTTP so all bets are off.
- j16sdiz 8y agoThe pubkey is delivered with the CD and signed with gpg, listed on public server. This is no longer secure then trusting the CA list in the preinstall Windows in pc.
- deleted 8y ago[deleted]
- rlucas 8y agoThis is a good synthesis here -- downloading and trusting a key over HTTP is folly, but then, so is trusting much of anything that "just works." If the whole PKI approach is to work, client has got to get trusting that public key right. In regular practice, that probably means checking it against a HTTPS-delivered version of same from an authoritative domain. (How far down the rabbit hole do we go? Release managers speaking key hashes into instagram videos while holding up the day's New York Times?)
- ecnahc515 8y agoYou joke, but we've seen with machine learning you can fake those kinds of "proof" videos too :P
- 3pt14159 8y agoNo, it also adds security. If someone steals a signing key then they also need to steal the HTTPS cert. Or control the DNS records and generate a new one or switch to HTTP. Adding an extra layer of encryption is like adding more characters on a password. Sometimes it saves your bacon, sometimes it was useless and came with performance drawbacks. If you still disagree with me, that's fine. But I want to hear why you continue to hold this opinion when worked for 1Password during Cloudbleed. https://blog.1password.com/three-layers-of-encryption-keeps-you-safe-when-ssl/tls-fails/ https://blog.1password.com/three-layers-of-encryption-keeps-...