91–100 of 132 posts
Honest question, for those who have done it: what are the downsides of allowing your whole site to be accessed via SSL? Obviously, you need to be a bit more diligent about making asset urls protocol-relative (which can be a PITA across a large, dynamically generated site), but are there any other gotchas? Server load? Reduced cache-ability?
Without the proper tuning https will be significantly slower than http.
What I take out of this, beside things I knew of already (and most others as well) is: * Chrome wants to FORCE you to buy an SSL certificate. * The guy suggest getting one from StartSSL BUT those are crap for 2 reasons: you can only have ONE domain, else you have to pay. The TOS are horrible. So, dear imperialviolet, if you want me to use certificates that your company trusts (and by extension, your users), get up wi…
Earlier quoted context omitted.
So the proxy server acts as a forced man in the middle? This has to be one of the most atrocious things I have ever experienced. Forcing a man in the middle is insane especially in a large company where there may well be a lack in competency. HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.
Are you arguing with me, or with reality? I can't tell, because the system I described is how corporate proxies work pretty much everywhere. If you want privacy against the administrators of your employer, don't use your employer's network to do things that need privacy.
The problem isn't necessarily what the employer sees, it's what the might employer keep around.
Earlier quoted context omitted.
Are you arguing with me, or with reality? I can't tell, because the system I described is how corporate proxies work pretty much everywhere. If you want privacy against the administrators of your employer, don't use your employer's network to do things that need privacy.
I don't see how my comment may be interpreted as starting an argument. I was simply replying on your comment on HTTPS just 'work'ing once you ignore the man in the middle attack. It's not privacy from an employer that is the underlying issue. It is the practice itself which should be frowned upon. People didn't spend their time trying to come up with the ability to have secure communications from point A to point B j…
But even if reasonable people could disagree about that policy decision: the reality is that people operating large corporate networks require the ability to control SSL/TLS sessions; for instance, there are whole industry verticals where accessing a private email server not controlled by your employer is grounds for automatic termination, because regulations require them to track and archive email messages.
Finally, and I'm repeating myself: I am describing the reality of most Fortune-500 enterprise networks. In most corporate networks, you cannot simply talk from your desktop out to the Internet; you are required to use a proxy. You're also almost certainly on an 10/8 IP address.
It's not clear to me from what docs that I have been able to find.
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…
All of these are good recommendations. Another technology to start preparing for is TACK. It allows you, the server owner, to control browser pinning of your certs while maintaining CA mobility. This gives you the control over your security that Google has over Gmail via Chrome cert pinning without having to issue a new browser build every time you change CAs. One way to think of it is like a domain transfer lock but…
Earlier quoted context omitted.
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…
So the proxy server acts as a forced man in the middle? This has to be one of the most atrocious things I have ever experienced. Forcing a man in the middle is insane especially in a large company where there may well be a lack in competency. HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.
Earlier quoted context omitted.
Do you realize that it's not the abstract concept of an enterprise using a browser, but a human being? Which, usually, is not the person administering the server. I'm all for nudging people to change their own behaviour to the better, but this is driving your principles home on the back of the user. Considering your use of the word "breakage": DannoHung is talking about a button that is actively being disabled in cer…
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…
Of course, I would still only run with "--ignore-certificate-errors" for the limited time the proxy has broken certificates or whatever...
Earlier quoted context omitted.
All of these are good recommendations. Another technology to start preparing for is TACK. It allows you, the server owner, to control browser pinning of your certs while maintaining CA mobility. This gives you the control over your security that Google has over Gmail via Chrome cert pinning without having to issue a new browser build every time you change CAs. One way to think of it is like a domain transfer lock but…
I see Moxie is one of the authors on the draft. Is this an outgrowth/pivot of Convergence?
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…
config.force_ssl = true