Firefox gets complaint for labeling unencrypted login page insecure
|
|
|
Comments (6)
Indeed, this comment on the Ars article sums up everything I would have said:
gautier wrote:Dear dgeorges, your biggest problem is not the lack of security on your website, this is easy to fix, your biggest problem is your total ignorance of the Internet security culture and of the security in general. Claiming on a public forum that your site have not been hacked during the past 15 years just open a joyful challenge to all the hackers playing around. I wish you good luck for the next 15 years because obviously after this pretty hilarious claim, you will stay on the hot target for some time.
I think it's a little off for Google, Firefox, etc to do this though. Just because a website uses https for traffic between the server and client doesn't reflect on the site's security, just vulnerability to man-in-the-middle attacks and traffic sniffing. Self-signed certificates generate alarming responses to the user in browsers - the self-signed certificate might actually be legitimately from the website trying to protect it's users. Rather than the server being compromised it's actually the user and their information that's at risk over plain connections.
The signed certificate mechanism has always been a mess. It's impossible to know what signatories the client has on their client (they might not have been updated). The list of trusted signatories provided by an OS manufacturer/browser/etc. should not necessarily be trusted outright and some may have been compromised or retired. While projects like Let's Encrypt try and plug the gap, browser warnings have suppressed the use of https.
Then there's the issue of security suites acting as proxies, creating a secure connection between the security suite and the server then using their own certificate between the security suite and the browser: it makes it look as though the connection is secure to the end user in their browser when it might not be - undermining protection from man-in-the-middle attacks.
In short, there is no substitute for user education. Anything less is just a placebo.
The signed certificate mechanism has always been a mess. It's impossible to know what signatories the client has on their client (they might not have been updated). The list of trusted signatories provided by an OS manufacturer/browser/etc. should not necessarily be trusted outright and some may have been compromised or retired. While projects like Let's Encrypt try and plug the gap, browser warnings have suppressed the use of https.
Then there's the issue of security suites acting as proxies, creating a secure connection between the security suite and the server then using their own certificate between the security suite and the browser: it makes it look as though the connection is secure to the end user in their browser when it might not be - undermining protection from man-in-the-middle attacks.
In short, there is no substitute for user education. Anything less is just a placebo.
Website seems to be offline now. Just a parking page.
>Self-signed certificates generate alarming responses
This is the "Trust in Cryptographic Signatures" problem. Encryption isn't the problem. It's the trust model.
Unfortunately, the 'secure' web has been based on poor trust models where the domain owner has had limited ability to self secure traffic. Certificate pinning is slightly better than simple certificate use. However, the certificate pinning is performed via web server configuration and so is compromised if the web server itself is breached. It would be better if there could be widespread use of public keys inserted into DNS for use as a trust anchor. Such as system could be protected via DNSSEC to provide a near impossible to break chain of cryptographic signatures verified all the way to the root DNS servers.
DKIM for email systems handles this wonderfully. There's no reason why such a system couldn't be used for web traffic as well.
This is the "Trust in Cryptographic Signatures" problem. Encryption isn't the problem. It's the trust model.
Unfortunately, the 'secure' web has been based on poor trust models where the domain owner has had limited ability to self secure traffic. Certificate pinning is slightly better than simple certificate use. However, the certificate pinning is performed via web server configuration and so is compromised if the web server itself is breached. It would be better if there could be widespread use of public keys inserted into DNS for use as a trust anchor. Such as system could be protected via DNSSEC to provide a near impossible to break chain of cryptographic signatures verified all the way to the root DNS servers.
DKIM for email systems handles this wonderfully. There's no reason why such a system couldn't be used for web traffic as well.
dotmatrix wrote:DKIM for email systems handles this wonderfully. There's no reason why such a system couldn't be used for web traffic as well.That's an excellent idea. The only hurdle would be DNS registrars that don't support long enough keys, they should upgrade anyway.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post

you may just not have noticed.
greetings, eMBee.