Live data from Hacker News

Google Will Soon Shame All Websites That Are Unencrypted

motherboard.vice.com

211–220 of 369 posts

Re: Google Will Soon Shame All Websites That Are Unencrypted

#212
post #32

Earlier quoted context omitted.

Isn't that what Let's Encrypt is aiming for? Install a package, which configures a cronjob for you? https://letsencrypt.org/howitworks/ Which could just even become a default but optional dependency of your distro's web server package, or part of your Docker container, or whatever.

Ok I'm new to this and I know it's still beta, but it seems: 1. Still WAY too complicated (look at all the stuff you have to know and type) 2. Doesn't seem to support my preferred OS (Windows) or web server (IIS) what-so-ever. Which is strange since, from my experience, installing certs in IIS is already far easier than in Apache and Nginx. (Although maybe that's why they perceive it as less of a priority?)

> 1. Still WAY too complicated (look at all the stuff you have to know and type)

I didn't realise that people getting SSL certs and administrating servers don't know how to read a literally one-page rundown of what to run. They also have helper scripts to make it much simpler.

> Which is strange since, from my experience, installing certs in IIS is already far easier than in Apache and Nginx. (Although maybe that's why they perceive it as less of a priority?)

nginx literally takes less than 10 minutes to set up not only SSL, but also CSP and several other very important security features.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#213

Why don't I like this? I don't think it's HTTPS.... I think I don't like that one company has this much power over the web. This seems awfully familiar...

I don't like this because I've always thought that HTTPS shouldn't be a mandatory baseline. It doesn't make a whole lot of sense to me that a random website with no financial transactions or anything should require HTTPS. [Edit: And thus, it makes less sense to me that the site should be penalized by anyone for NOT having it.]

"Ah, yes. Bob's Trivia Emporium has HTTPS. I know this is really Bob's site and that the data is from his site."

If anyone has compelling arguments to the contrary, I'm open to hearing them.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#214
post #76
post #64

Which is hilarious because the reason I can't switch The New Yorker website to HTTPS is because of ads - which I'm getting from Google DFP which allows non-secure ad assets. In short; Google will penalize me because I use Google. The universe has a sense of humor.

Similarly, Google claimed they would start penalizing websites that showed full-page ads for mobile apps instead of showing you the website. But every single time I try to get to Gmail, or Drive, or Calendar, or any Google service on the web using a mobile device, I'm shown a full page ad for a mobile app. Google has been doing this for years, and it seems like it's also been a year since they said they'd punish all…

They also sell full page ads now: https://support.google.com/adxseller/answer/6068103?hl=en

Re: Google Will Soon Shame All Websites That Are Unencrypted

#215
post #104
post #23

Why do we have to go through this whole SSL certificates thing and can't just have a simple, automatically secure, I-do-nothing-and-my-website-is-secure protocol? Seriously though. If secure is the default from now on, why can't it actually be the default?

Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default.

> Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default.

Becuase you either have to do DH and all of the key negotiation anyway (at which point you already have a key, so why not encrypt and HMAC at the same time?). If you had two systems for this, it would be pointlessly inefficient (why have two DH key exchanges for the same channel).

Re: Google Will Soon Shame All Websites That Are Unencrypted

#216
post #64

Which is hilarious because the reason I can't switch The New Yorker website to HTTPS is because of ads - which I'm getting from Google DFP which allows non-secure ad assets. In short; Google will penalize me because I use Google. The universe has a sense of humor.

Google DFP allows it because publishers (e.g. the New Yorker) aren't ready to switch all their traffic HTTPS. If they wanted to they could turn the switch and be HTTPS and tell DFP to only serve secure creatives.

One of the larger difficulties for publishers is that many of the 3rd party SSPs aren't ready to go full HTTPs and so publishers are reluctant to make the switch because it reduces demand sources.

Disclaimer: Work for Google in advertising

Re: Google Will Soon Shame All Websites That Are Unencrypted

#217
post #154

Earlier quoted context omitted.

If you don't have a way to confirm that the key you're seeing from the other site is right, you're inherently vulnerable to a man-in-the-middle attack which removes the benefits of the encryption against the attacker. https://en.wikipedia.org/wiki/Man-in-the-middle_attack httpS://en.wikipedia.org/wiki/Zooko's_triangle It's not clear that the certificate authority system was or is the best solution to this problem, bu…

However, having one and not the other isn't totally useless. Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit). That would be at least be useful for self-signed certs (th…

> However, having one and not the other isn't totally useless.

> Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit).

Isn't that what you do when you make a security exception for a self-signed certificate? Having that enabled by default lulls people into a false sense of security.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#218
post #181

Earlier quoted context omitted.

SSL hasn't required a separate IP since Windows XP. And XP no longer has any security support, so anyone running it has bigger problems.

Guess you're right, fair enough. I still don't agree with putting a scarlet letter on these types of sites though.

Nothing short of that will get HTTPS adoption to approach 100%. Many people have commented that it seems odd to complain about broken HTTPS but not about HTTP; I agree with that. As long as browsers show unencrypted HTTP as "neutral" rather than "bad", far too many sites simply won't care. This has been a long and gradual step, but it needs to happen for HTTP to finally go away.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#219

Earlier quoted context omitted.

But the worst case scenario with SSH MitM isn't someone being able to eavesdrop on your connection. But someone pretending to be the server, which is hardly as serious. (Unless you're using password auth, in which case you deserve to get owned)

If someone impersonates your server, it can then pass the authentication request to the original, and gain full MITM without your knowledge. Yes, even if you use public key auth.

I will personally pay you the sum of 500 Bitcoins if you can demonstrate a realistic active MitM attack on OpenSSH that allows an active network level attacker to "pass the authentication request to the original" and gain full MitM.

Conditions:

Public key authentication must be used for authentication.

If it's possible to perform the attack passively(e.g on pcaps), it doesn't qualify.

This attack has to affect setups using both the latest OpenSSH client and server with default configuration.

This attack has to be able to be performed in realtime using the processing power of a 2015 macbook model of your choosing.

This attack cannot rely on attacker having any other access but the ability to tamper with the connection however much he wants.

This attack cannot rely on known flaws in the encryption algorithms.

With full MitM I am referring to the ability to at least access the plaintext communications between the client and server. Eg if the user runs 'sudo', the ability to see the password entered.

Please consider this offer legally binding, if you have any questions I will answer them and you can consider the answers binding too.

Good luck.

Post reply on HN