3 ms·
I suppose it's nice to have the rationale written out somewhere, but does anyone anywhere actually balk at being required to use HTTPS?
by skywhopper 13y ago
I suppose it's nice to have the rationale written out somewhere, but does anyone anywhere actually balk at being required to use HTTPS?
- XorNot 13y agoPlausible deniability is frequently more useful then encryption. The probability of someone messing with my packets in-flight is low. But TLS creates the problem that you are possibly then able to prove that the packets I sent came from me.
- gcp 13y agoThis problem doesn't exist on the client side, no? It's not like we provide client certificates when using HTTPS/TLS. You're authenticating (typically) with passwords which unfortunately were stolen when your (random service goes here) account got hacked.
- hdevalence 13y agohttp://blogs.computerworld.com/privacy/23698/google-customers-you-will-use-https http://blogs.computerworld.com/privacy/23698/google-customer... "Since when is removing consumer choice a good thing? Does Google really know better than you do what your security posture should be for your Gmail accounts?" Yeah, what do those Google security engineers know, anyways?
- MindTwister 13y agoI'm actually more intrigued by this part "an encryption methodology that I suspect the NSA can probably defeat anyway." If the premise is "I don't need security, because the most powerful intelligence agency in the world can break it anyways", then why not go ahead and give us the PIN for your debit card anyway.
- backwoodshacker 13y agoI realise I'm going to be in the 0.1% minority on this, but yep, I do. Three reasons. First, I've been enough places where Internet connectivity is so poor that HTTPS effectively breaks the connection. I used to stay half the week somewhere where the only connectivity was a dire, over-saturated 3G link. I couldn't browse HTTPS sites unless I was very lucky. Second, I'm uneasy with the implication that "HTTPS=secure", in that it absolves the user of taking any responsibility for their own security. A site can require a HTTPS connection and still store the password in cleartext, for example; so unless you have a unique password, this "secure" site can still screw you. Yeah, I know HN readers understand the difference, but IMX most people dimly understand a binary distinction between "secure site" and "not secure site" and that's it. Third and related, the corollary of "HTTPS=secure" is that "sites that only use HTTP = insecure". This is leading to a requirement that any guy who builds a website with login functionality needs to implement HTTPS, and that saddens me. The web becomes less democratic, less meritocratic, the more technical hurdles we require. But, like I say, I realise 99.9% of people disagree with me.
- sitkack 13y agoIf this is your situation, you have other technical problems that, yes 99.99% of the people do not have. Something like a UDP proxy with FEC and proxy side stripping of cruft and external requests. Downgrading from https -> http is only solving a portion of your problem.
- dragonwriter 13y ago> Third and related, the corollary of "HTTPS=secure" is that "sites that only use HTTP = insecure". This is leading to a requirement that any guy who builds a website with login functionality needs to implement HTTPS, and that saddens me. HTTPS may not be secure, but HTTP (over the public internet, at least) is definitely insecure. If you have login functionality that matters, rather than serving as a very basic deterrent to accidentally getting somewhere you shouldn't be, yes, you need to use HTTPS.