TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Chrome and misleading security information

1 点作者 tcarnell将近 13 年前
If you use a self-signed certificate to secure a website, Google Chrome's reaction is somewhat dramatic and I would say inaccurate and misleading. Below is a screenshot (sorry, you'll have to accept the certificate to view it!):<p>https://puntoshare.com/resource/BvihzPSc<p>The Google Chrome url bar with the "https" and "padlock" icons crossed out with a bold red line would suggest to the user that the page is not encrypted, does not use HTTPS and is 'not safe'.<p>Of course, this is not true and the Chrome 'site information' text clearly states that the site is secured with 256-bit encryption (and displays a reassuring green padlock icon). However, I am sure very few users actually view the 'site information' text.<p>I agree that the certificate does not verify the identity of the site, but this is a separate issue, right? I just want to ensure the user that information passed to/from the server is encrypted.<p>We visit unsecured websites all the time and we have no idea how safe they are or who owns them and browsers give us absolutely no warnings, so I am a bit disappointed that when I do attempt to increase security for the end-user the browser works against me, implying the site is unsafe.<p>Can't Google bypass the CA's and implement their own site authentication mechanism (for free)?

5 条评论

dchest将近 13 年前
Did you read the warning? It pretty much answers your question:<p>"This may mean that the server has generated its own security credentials, which Google Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications."<p><i>I just want to ensure the user that information passed to/from the server is encrypted.</i><p>Self-signed certificate doesn't guarantee the encrypted communication to/from your server. An attacker can intercept your handshake request and provide their own self-signed certificate.<p>You can create your own CA, sign a server certificate with it, and then ask users to install your CA certificate into their browsers.<p>Or you can get a free certificate from StartSSL.<p>Alternatively, you can contribute to some replacement for TLS.
评论 #4155888 未加载
评论 #4155853 未加载
Piskvorrr将近 13 年前
What makes Chrome special here? AFAIK, <i>every</i> browser (FF, IE, Opera, you name it) treats HTTPS with problems as "extremely scary, alert the President" (which is, IMNSHO, absolutely correct behavior - "this site says it's HTTPS://whatever, but I'm unable to verify this, so let's crash and burn - it might just as well be <a href="https://evilsite.evil" rel="nofollow">https://evilsite.evil</a>, for all I know"), whereas unsecured, plain HTTP is seen as "meh, whatever."<p>Moreover, "why can't Google fix the Internet?" is, essentially, saying "do away with <i>the other</i> CAs, and make Google the <i>ultimate</i> CA" - doesn't fix the problem, plus makes it worse.<p>(FWIW, there are cheap SSL certs out there which are signed by known CAs and thus don't trigger the security error.)
评论 #4155803 未加载
mooism2将近 13 年前
Without verifying the identity of the site somehow, you are vulnerable to a mitm attack. So no, it's not a separate issue.<p>What is your proposed site authentication mechanism that Chrome should use (and does it scale to Firefox, Safari, etc)?
评论 #4155817 未加载
Sambdala将近 13 年前
The red warning page you have to click through also seems irresponsible to use in cases like this.<p>It's the same page you get when there's malware on a site.
评论 #4155840 未加载
tcarnell将近 13 年前
I think I would be more relaxed if browsers used an additional icon to indicate if a site identity is verified or not.<p>And just because somebody has paid for a site certificate and gets a nice green padlock icon on the URL bar does not mean they wont misuse peoples personal information, does it?