3 ms·
The top answer here is good: http://security.stackexchange.com/questions/258/what-are-the-pros-and-cons-of-site-wide-ssl-https http://security.stackexchange.com
by seanwilson 11y ago
The top answer here is good:
http://security.stackexchange.com/questions/258/what-are-the-pros-and-cons-of-site-wide-ssl-https http://security.stackexchange.com/questions/258/what-are-the...
"Since most of the other answers here deal with the downsides of site-wide SSL (mainly performance issues - btw these can easily be mitigated by offloading the SSL termination, either to an SSL proxy box, or an SSL card), I will point out some issues with having only the login page over SSL, then switching to non-SSL:
- The rest of the site is not secured (though this is obvious, sometimes the focus is too much on just the user's password).
- The user's session id must be transmitted in the clear, allowing it to be intercepted and used, and thus enabling the bad guys to impersonate your users. (This is mostly what the Firesheep hubbub was about).
- Because of the previous point, your session cookies cannot be marked with the secure attribute, which means that they can be retrieved in additional ways.
- I have seen sites with login-only-SSL, and of course neglect to include in that the Forgot-password page, the Change-password page, and even the Registration page...
- The switch from SSL to non-SSL is often complicated, can require complex configuration on your webserver, and in many cases will pop up a scary message for your users.
- If it's ONLY the login page, and f.e. there is a link to the login page from your sites home page - what is to guarantee that someone won't spoof/modify/intercept your homepage, and have it point to a different login page?
- Then there is the case where the login page itself is not SSL, but only the SUBMIT is - since that's the only time the password is sent, so that should be safe, right? But in truth that removes from the user the ability to ensure ahead of time that the password is being sent to the correct site, until its too late. (E.g. Bank of America, and many others)."
I imagine top YouTube contributors would be pretty annoyed if their account got hijacked.
- ausjke 11y agoisn't youtube's content mostly if not all freely accessible already? the premium portion can be hosted as ssl-only, what about the rest 99% of the content that is public already, why do we need care about hijacking in this case?
- seanwilson 11y agoFor the extra complication of making a mixed HTTP and HTTPS site, what benefit are you gaining?
- ausjke 11y agonginx and apache can support http/https in parallel fairly easily, not much extra complication per se. the benefits are listed in a post below. I was chatting with a youtube engineer last night and she told me that she does not recall a wide discussion on disabling http fully, I thus submitted a request in youtube's forum and see how it goes.
- seanwilson 11y ago> nginx and apache can support http/https in parallel fairly easily, not much extra complication per se. the benefits are listed in a post below. There are extra complications besides the server setup. For example, it's harder to avoid mixed content errors on HTTPS pages, you couldn't just use the "secure" flag on all cookies and you need to be careful not to send passwords or session data over HTTP. Many sites have login forms on HTTP pages that then send you over to the HTTPS site for example but this isn't secure. Not saying it has no benefits, but mixing HTTP and HTTPS does have complications. > I was chatting with a youtube engineer last night and she told me that she does not recall a wide discussion on disabling http fully, I thus submitted a request in youtube's forum and see how it goes. Great, I'd be interested to know the reason as well.