Live data from Hacker News

Living with HTTPS

imperialviolet.org

111–120 of 132 posts

Re: Living with HTTPS

#111
honest question: why can't banks when customers open a new account, give them a card with 1. the bank's ip addresses (in each region) and 2. their printed public key (ssl or ssh format). and why doesn't the bank ask for a public key from each customer? in-person key exchange.

no one even pays attention to the client side of ssl. how many of you use your own ssl certificates? you basically can't under the cert authorty scheme. it's a racket and no one is going to pay for these. and do the banks even care? they use tactics like cookies and follow-up emails to verify customers (hardware).

and why does the bank have to be able to switch their ip address without telling anyone? what if the same was true for phone numbers? people would be like wtf? load balancing? c'mon. too difficult ot type? thnk about the trade-offs in security, all for the sake of not looking at a number? ipv4 is no longer than an area code and phone number. just tell people where your servers are and let them choose the one that is nearest. which incidentally, contrary to conventional wisdom, is not _always_ the one that will be the most responsive in the ever-changing state of the network.

there's nothing more annoying than being subjected to using trial and error and you are not allowed to do any of the trial when the errors start coming. out of your control.

what happened to the concept of "important numbers"? are we to believe you only need to remember "google.com" or "yourbank.com"? that's a security problem waiting to happen.

second honest question: why does bank website need to embed links to third party reources and require that customers enable their browsers to access all these indiscriminantly (user doesn't get to choose) and to enable javascript?

is javascript needed for security of a connect or to accomplish a financial transaction? because that's all i need from the bank website.

i think we're past the point where customers need to be enticed to use the web to do things like banking and shopping. they're going to be forced to. so we can forgo the silly demonstrations and gratuitous use of javascript. save for "show HN".

what we need is simplicity, reliability and security.

Re: Living with HTTPS

#112
post #98
post #67

Earlier quoted context omitted.

The button he's asking for is "disable TLS security". If he wants to disable TLS security, there's a right way to do it: by installing the proxy's cert. If you read 'agl's talk, you'd see that the reason the button is hidden is that it is one of the Internet's great security flaws: a workflow embedded into most browsers that demands users to learn to disable TLS security. So, I find this argument you're making to be…

Anyway, I would say "--ignore-certificate-errors" is an acceptable workaround here. If your proxy is already intercepting all HTTPS traffic, then there's really no benefit in the client browser also verifying certificates. Of course, I would still only run with "--ignore-certificate-errors" for the limited time the proxy has broken certificates or whatever...

Even with a corporate proxy intercepting SSL connections, individual browsers are still protected against attacks on the local network involving SSL impersonation (rogue access points, DHCP or ipv6 neighbor announcement abuse...).

Companies have their firewall infrastructure locked down (hopefully), but lan segments (except in high-security environments) not as much.

Re: Living with HTTPS

#113
post #97

Earlier quoted context omitted.

This is far more common than you might expect. You just need to push you're company's internal CA to all your client computers, and bam , MITM for everything!

Yes enterprise customers want to decrypt and inspect all traffic, for legitimate and sometimes sketchy reasons.

HIPAA requires it as far as I know, and I am sure other regulatory frameworks probably do.

Re: Living with HTTPS

#114

Earlier quoted context omitted.

Yes enterprise customers want to decrypt and inspect all traffic, for legitimate and sometimes sketchy reasons.

HIPAA requires it as far as I know, and I am sure other regulatory frameworks probably do.

HIPAA does not require traffic monitoring.

Re: Living with HTTPS

#116
post #4

This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped to startups, down to the order in which he gives the advice: * Enable HSTS * Don't link to HTTP:// javascript resources from HTTPS pages * Set the secure flag on cookies Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set. The only quibble I might have is the fatalism he has about mixed-securit…

if you need an absolute URI for any assets, then just use: //www.example.com/path/to/asset.js this will then use the same transport as the containing page uses.

That's a great suggestion that's often overlooked.

At Quantcast we tried to use "//" without the protocol in our tags (to eliminate the need for a separate http: and https: tag), but we had a huge number of complaints about a bug in our tag (missing http:!). Users also tried to be helpful and add in the "http:" and then complained when it broke. In the end we went with two separate tags to reduce the support burden, despite the added complexity of having to explain the two tags.

Re: Living with HTTPS

#117
post #91
post #89

Earlier quoted context omitted.

Without the proper tuning https will be significantly slower than http.

Could you clarify what "proper tuning" entails?

SSL/TLS is not computationally expensive any more[1] but there are some things that can help/hurt discussed in the footnote.

[1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

Re: Living with HTTPS

#118
post #48

Please for the love of god, if you're working at google and read this: Add a deeply set option to FORCIBLY enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen. I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature fo…

It's very straightforward for a proxy to have its own CA=YES certificate and mint/sign certs for every HTTPS site the proxy sees on the fly. If you have a corporate proxy that is intercepting HTTPS traffic, that is what it should be doing. Then, the proxy makes its certificate available to users, you download it, and add it to your CA certs via the UI that browsers provide for that; HTTPS magically appears to work ag…

Yeah, that's what should be happening, but sometimes the software breaks, or the security restrictions on the certificates accepted by the browser changes and the vendor of the product doesn't update fast enough or the certificate that's installed is out of date or whatever.

In which case I end up shit creek without a paddle because there's no way to temporarily disable the security feature.

And I do not have control over the Proxy server because I'm not in the fucking security team.

Re: Living with HTTPS

#119
post #30

Please for the love of god, if you're working at google and read this: Add a deeply set option to FORCIBLY enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen. I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature fo…

The bypass button only disappears for HSTS sites. Do you have a proxy server that's intercepting these connections and has a broken certificate? You can disable all certificate checking with --ignore-certificate-errors but it is as bad as it sounds. Rather, to correctly support MITM proxies you should install their CA certificate locally.

I suppose I can use that the next time it happens, but that's a bit more overkill in terms of disabling warnings than I'm looking for :/

Re: Living with HTTPS

#120
post #62
post #59

Earlier quoted context omitted.

How exactly does "I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself." become "train the staff to be blind to security warnings"?

If you know what you're doing, get the CA=YES cert from your proxy and install it in your browser.

The cert itself was broken in the most recent case.
Post reply on HN