Google Further Pushes HTTPS by Marking Websites as "Not Secure"

FrgMstr

Just Plain Mean
Staff member
Joined
May 18, 1997
Messages
55,602
Starting in July of this year, Chrome browser will start noting that sites that do not use Secure Socket Layer encryption as being "Not Secure." Of course that does not mean you are not visiting a malicious website, but HTTP encryption is a big step in the security direction. Google also has new sets of tools to help website admins migrate to HTTPS.

For the past several years, we’ve moved toward a more secure web by strongly advocating that sites adopt HTTPS encryption. And within the last year, we’ve also helped users understand that HTTP sites are not secure by gradually marking a larger subset of HTTP pages as “not secure”. Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.
 
Just had Firefox warn me of a possible unsecure site that had https, strangely enough it was the Pillsbury website because I clicked on a link for some meatball recipe... didn't feel like tempting fate over a recipe though.
 
Not all HTTP is bad.

You're right, all http is shit now. HTTPS is always the answer, performs better (since all current CPUs have a micro processor for AES) and keeps your traffic hidden from snooping ISPs. Which is very useful since the GOP shredded our privacy rights last year in favor of corporations.
 
You're right, all http is shit now. HTTPS is always the answer, performs better (since all current CPUs have a micro processor for AES) and keeps your traffic hidden from snooping ISPs. Which is very useful since the GOP shredded our privacy rights last year in favor of corporations.

So the internal office web site (only accessible while on the office network), which has nothing more than links to other resources and office holiday pictures now needs to have a certificate purchased/installed and switched to HTTPS? Seems like a waste if time & money to me.
 
You're right, all http is shit now. HTTPS is always the answer, performs better (since all current CPUs have a micro processor for AES) and keeps your traffic hidden from snooping ISPs. Which is very useful since the GOP shredded our privacy rights last year in favor of corporations.

How well does it work on 8-10 year old embedded processors? Think non-computer appliances that have a web interface for management.
 
So the internal office web site (only accessible while on the office network), which has nothing more than links to other resources and office holiday pictures now needs to have a certificate purchased/installed and switched to HTTPS? Seems like a waste if time & money to me.

Thanks to letsencrypt there is no cost for SSL any longer for small sites / companies like this.
 
There are a lot that don't care. I've mentioned this to a few of my clients and they were like

  • "Ehh, the site will still work."
  • "We really don't care what it will say in Chrome."
  • "We do most of our stuff via Twitter and Facebook, so we don't really care about our website."
  • "Not worth the money."
Just a few of the things I've heard. In the end, there will still be plenty that will refuse. Despite it being easy and cheap to implement. They just see it as additional configuration to something that already works.
 
You're right, all http is shit now. HTTPS is always the answer, performs better (since all current CPUs have a micro processor for AES) and keeps your traffic hidden from snooping ISPs. Which is very useful since the GOP shredded our privacy rights last year in favor of corporations.
Prevents ISP's from buffering common websites increaing traffic congestion that costs consumers money to offset. Instead of caching one copy of cnn.com they have to pull it new everytime.
Increases you browsing fingerprint to make it easier for your web destination to know who you are. This is critical for Google to defeat any counters you've employed.
ISP still knows where your'e going.
ISP can man in the middle your certs and watch your content anyway.

Considering everywhere you go probably tries to monetize your presense, having a fingerprint let's everyone know what you're doing. Thinking your destination, their ISP, your ISP is not de-anonymizing you and monetizing your activity is wishful thinking. Those two don't have to be the same entity.
 
Prevents ISP's from buffering common websites increaing traffic congestion that costs consumers money to offset. Instead of caching one copy of cnn.com they have to pull it new everytime.
Increases you browsing fingerprint to make it easier for your web destination to know who you are. This is critical for Google to defeat any counters you've employed.
ISP still knows where your'e going.
ISP can man in the middle your certs and watch your content anyway.

Considering everywhere you go probably tries to monetize your presense, having a fingerprint let's everyone know what you're doing. Thinking your destination, their ISP, your ISP is not de-anonymizing you and monetizing your activity is wishful thinking. Those two don't have to be the same entity.


They absolutely can NOT MITM your ssl cert chain without a big nasty warning on your browser. That's the whole point of ssl. If this were possible, ssl would be 100% useless.

Caching shouldn't be done at the ISP anyway. I wouldn't trust them to keep the content up to date, especially on a site like cnn (not that I go there or any other mtm sites).

The rest is mitigated with no-script, ghostery and ublock. Add a VPN and you are much better off, especially if the end point is outside of the US.
 
They absolutely can NOT MITM your ssl cert chain without a big nasty warning on your browser. That's the whole point of ssl. If this were possible, ssl would be 100% useless.

Caching shouldn't be done at the ISP anyway. I wouldn't trust them to keep the content up to date, especially on a site like cnn (not that I go there or any other mtm sites).

The rest is mitigated with no-script, ghostery and ublock. Add a VPN and you are much better off, especially if the end point is outside of the US.
Except 99% of people don't understand this and will click whatever ok button there is to continue onward....
 
Don't get me wrong TLS in https is important. It makes sure that no one can snoop on what you are doing outside of just getting the top level domain.

Now if there only were a verification that signed certificates are actually issued to who they claim to be, it could become REALLY useful.

Right now anyone can get a certificate claiming they are someone else.
 
They absolutely can NOT MITM your ssl cert chain without a big nasty warning on your browser. That's the whole point of ssl. If this were possible, ssl would be 100% useless.

Caching shouldn't be done at the ISP anyway. I wouldn't trust them to keep the content up to date, especially on a site like cnn (not that I go there or any other mtm sites).

The rest is mitigated with no-script, ghostery and ublock. Add a VPN and you are much better off, especially if the end point is outside of the US.

They can create a webpage with a similar name (lower case l vs number 1 or capital O vs zero 0, etc. etc.) and install a certificate they created themselves using one of the web services out there, and your browser will just accept it as if it were the real thing.

We have long taught our senior citizens to "look for the https", but in reality, they can have an https in thddress bar, no warning and still be on a malicious site.

The "blindly issuing certificates" loophole needs to be plugged. The certificate issuing agency should be responsible for verifying that the requester actually is who they appear to be, and liable for any damages if they aren't.
 
They can create a webpage with a similar name (lower case l vs number 1 or capital O vs zero 0, etc. etc.) and install a certificate they created themselves using one of the web services out there, and your browser will just accept it as if it were the real thing.

We have long taught our senior citizens to "look for the https", but in reality, they can have an https in thddress bar, no warning and still be on a malicious site.

The "blindly issuing certificates" loophole needs to be plugged. The certificate issuing agency should be responsible for verifying that the requester actually is who they appear to be, and liable for any damages if they aren't.


That would require the user to click the wrong link to the site. They can't just redirect your request to google to a fake g00gle.com address with associated 3rd party cert. But clicking bad link/urls is a whole other issue, and is not a weakness in SSL. People will always be the weakest link in security.

The browsers now require you to jump through hoops to add an exception if the SSL cert doesn't match the page or is expired, and gives pretty clear warnings about how insecure it is. You'd have to be an idiot to continue doing that on a public site.

And most ssl providers at minimum require you to add a txt record on your domain to confirm ownership, including letsencrypt. But you're right, it's not always a requirement, and a couple big CA's have gotten in trouble for issuing certs without proper verification.
 
That would require the user to click the wrong link to the site. They can't just redirect your request to google to a fake g00gle.com address with associated 3rd party cert. But clicking bad link/urls is a whole other issue, and is not a weakness in SSL. People will always be the weakest link in security.

The browsers now require you to jump through hoops to add an exception if the SSL cert doesn't match the page or is expired, and gives pretty clear warnings about how insecure it is. You'd have to be an idiot to continue doing that on a public site.

And most ssl providers at minimum require you to add a txt record on your domain to confirm ownership, including letsencrypt. But you're right, it's not always a requirement, and a couple big CA's have gotten in trouble for issuing certs without proper verification.


All true.

IMHO, I would have browsers invalidate all current certs, and put a requirement in place that all certificate authoring services not only verify ownership using the text string method, but also check the URL and other elements to make sure the site doesn't look like it is trying to impersonate something else.
 
Google think they going to defeat ISPs anti NN moves this way? Aint happening... Https? Your traffic goes last.. its all https? Well it is going to be slow from know on.
 
All true.

IMHO, I would have browsers invalidate all current certs, and put a requirement in place that all certificate authoring services not only verify ownership using the text string method, but also check the URL and other elements to make sure the site doesn't look like it is trying to impersonate something else.

Cert authorities aren't security firms. I would leave creating a URL blacklist to someone else.
 
Cert authorities aren't security firms. I would leave creating a URL blacklist to someone else.


That's supposed to be done at the domain registrar level. They are no longer supposed to sell domains that are purposely deceiving or legitimate domains spelled wrong.
 
HTTPS is always the answer, performs better (since all current CPUs have a micro processor for AES)

HTTPS never performs better than HTTP. It is strictly more work and bandwidth to use HTTPS, and therefore slower. It's a low cost that's worth paying, but it's still a *cost* at the end of the day.
 
Thanks to letsencrypt there is no cost for SSL any longer for small sites / companies like this.

There is no cost for the certificate. There is a cost for the additional labor required to set it up.

Still my point stands: not every website needs HTTPS. HTTP is still a valid use case.
 
They absolutely can NOT MITM your ssl cert chain without a big nasty warning on your browser. That's the whole point of ssl. If this were possible, ssl would be 100% useless.

Caching shouldn't be done at the ISP anyway. I wouldn't trust them to keep the content up to date, especially on a site like cnn (not that I go there or any other mtm sites).

The rest is mitigated with no-script, ghostery and ublock. Add a VPN and you are much better off, especially if the end point is outside of the US.
I've heard this explained better in other places. But I don't have time to find it. I think the trick is to leverage a root certificate already on your system.
http://www.zdnet.com/article/how-the-nsa-and-your-boss-can-intercept-and-break-ssl/
 
Thanks to letsencrypt there is no cost for SSL any longer for small sites / companies like this.

That is assuming that your can expose your device to the public internet & your application is a webserver.

I haven't yet figured out how LetsEncrypt issues ssl certs for ftps, imaps, pops, etc. You can probably do it by hand, but at that point, it's easier to just buy a 2-3 year domain validation certs for a few $/year, rather than spend the time to install LE certificates 8-12 times manually in the same time period.

With the amount of phishing certs LE issues and washes their hands of, It wouldn't surprise me to see larger organizations stop trusting LE as a CA. I haven't seen this yet, but it wouldn't surprise me.
 
Last edited:
There is no cost for the certificate. There is a cost for the additional labor required to set it up.

Still my point stands: not every website needs HTTPS. HTTP is still a valid use case.
This helps push the riff-raff further from the front pages. The self maintained sites are soft-censored since they exhibit wrong think and even worse aren't advertising through a corporate service. Google an advertising company wants the webspace full of ads and people who will host them.
 
This helps push the riff-raff further from the front pages. The self maintained sites are soft-censored since they exhibit wrong think and even worse aren't advertising through a corporate service. Google an advertising company wants the webspace full of ads and people who will host them.

Wrong think?

Also as people have pointed out SSL is not a panacea...
 
HTTPS never performs better than HTTP. It is strictly more work and bandwidth to use HTTPS, and therefore slower. It's a low cost that's worth paying, but it's still a *cost* at the end of the day.

Except it has compression built in, and your CPU has a microprocessor to offload the processing to.... And there is no extra bandwidth (Unless you mean the 4 packets it sends during the initial handshake....), HTTPS is just sending encrypted (compressed) packets instead of plain text packets. I thought the same thing as you, then did some research. HTTPS is better than HTTP and should always be used on anything publicly accessible (even internally for extra security from snooping malware).

I've heard this explained better in other places. But I don't have time to find it. I think the trick is to leverage a root certificate already on your system.
http://www.zdnet.com/article/how-the-nsa-and-your-boss-can-intercept-and-break-ssl/

Still doesn't work that way. They cannot intercept the traffic and send you a different cert without your browser sending an alert. This can be setup in companies with Active Directory, but that requires setting up a GPO that pushes the proxies cert to your machine as trusted, so you browser does not complain. Here's a quote from your article:

"The SSL proxy intercepts traffic between your computer and the Internet. When you surf to a "secure" site, it, and not your browser, get the real Web server certificate and handles setting up a perfectly good SSL connection between it and the Web server. The proxy then sends you a digital certificate, which looks like the Web server's certificate, and sets up a "secure" connection between your browser and the proxy.

If your company has set up the proxy correctly you won't know anything is off because they'll have arranged to have the proxy's internal SSL certificate registered on your machine as a valid certificate. If not, you'll receive a pop-up error message, which, if you click on to continue, will accept the "fake" digital certificate. In either case, you get a secure connection to the proxy, it gets a secure connection to the outside site -- and everything sent over the proxy can be read in plain text. Whoops."
 
Last edited:
Back
Top