Hacker News new | past | comments | ask | show | jobs | submit login

So disable secure cookies by default for self-signed certs. The scary warnings can be shown when the user tries to enable them.



In other words, "open users up to social engineering attacks to make my web-dev life easier".


You misinterpreted the above commenter. The suggestion is to disallow self-signed contexts access cookies set in authoritative contexts.


I don't see that as the biggest problem. If we repeat what was said in the above comment:

> ...disable secure cookies ... for self-signed certs. ... the user ... enable[s] them.

So you make a self-signed cert for your website which needs secure login, and you tell your users to turn on secure cookies so that you can safely store their credentials in the browser. Then your website gets MITM'ed with another self-signed cert, which either

  1. can access the same cookies, because the domain is the same
  2. can't, because the cert is different
But in the second case, you've already conditioned users to log in to your website with the cert being self-signed, so they'll just log in again. If the browser complains that the attacker's cert isn't the same as the old cert, or makes the user re-enable secure cookies with a warning, then the user has been conditioned to do that too - and an extra message of "we changed the cert, ignore your security warnings" will convince lots of users with doubts.


The convoluted and unlikely scenario you describe is currently possible with HTTP and non-secure cookies (the website admin is setting the cookies and can choose to define them as secure or not).

Using a self-signed cert. isn't secure. What's being discussed is whether it's worse than HTTP. It isn't.


Browsers now try to detect and warn about credential forms which are submitted over HTTP. Any website admin who tries to convince users to ignore security warnings about HTTP is somewhere between seriously negligent and evil.

>What's being discussed is whether it's worse than HTTP. It isn't.

I disagree. The self-signed cert approach tries to carry with it the trappings of proper HTTPS, but it results in a bigger attack surface. Every additional bit of complexity that can be added to describing the "safe browsing experience" to the end user is an additional chink in the public armour. This is why I originally called it "open users up to social engineering attacks to make my web-dev life easier".

Since the self-signed cert is not secure, admins should have no reason not to simply use HTTP. In fact, this is where the discussion has gotten to now: self-signed certs can't even do safe login. What makes the self-signed cert worse is that for some reason people are insisting on using it anyways.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: