In Encryption Push, Chrome Flags HTTP Sites as 'Not Secure' (zdnet.com)

On Tuesday, Chrome started marking sites that don't use HTTPS as "not secure." From a report: First announced two years ago, Google said it would flag any site that still uses unencrypted HTTP to deliver its content in the latest version of Chrome, out Tuesday. It's part of the company's years-long effort effort to gradually nudge more webmasters and site owners into adopting HTTPS, a secure encryption standard for data in transit. Any site that doesn't load with green padlock or a "secure" message in the browser's address bar will be flagged -- and shamed -- as insecure.

[...] According to nightly data compiled by security experts Troy Hunt and Scott Helme, roughly 100 of the top 500 websites are still serving their pages over unencrypted HTTP -- all of which will today be flagged as "insecure." Many of those sites -- like Baidu, JD.com, and Google.cn -- are Chinese language sites, but many popular Western sites -- including BBC.com, DailyMail.co.uk, and Fedex.com -- are HTTP. Of the top million sites, a little over half do not redirect to HTTPS. Chrome 68 also brings with it Page Lifecycle API, and the Payment Handler API. From a report: The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above. As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.

Comments

MitM https proxies should be flagged too

[nyet]

All of this is pointless as long as we encourage corp IT firewall admins to completely break https with their MitM proxies that use fake wildcard certs and bogus CAs as part of a GP push.

Re:MitM https proxies should be flagged too

[Anonymous Coward]

All of this is pointless as long as we encourage corp IT firewall admins

How can you "flag" a site that uses a CA that's in the browsers CA store? That's how these MiTM proxies work.

Unless you favor a completely centralized approach where nobody can question the wisdom of the browser and/or OS makers on which CA authorities to trust, you can't really stop these admins. I hate it too, but you can't fix this one with the browser, you have to address the real problem, the paranoid admins who want to sniff everything.

Re: MitM https proxies should be flagged too

[Anonymous Coward]

DNS CAA, HPKP, and a few other options exist.

Re:MitM https proxies should be flagged too

[Anonymous Coward]

Corps can do what they please with their own equipment on their own networks.

Re:MitM https proxies should be flagged too

[Wrath0fb0b]

All of this is pointless as long as we encourage corp IT firewall admins to completely break https with their MitM proxies that use fake wildcard certs and bogus CAs as part of a GP push.

It's not "breaking" HTTPs, any more that distributed authorized_keys "break" SSH. The owner of Group Policy on a machine has (by definition) the authority to set HTTPs policies, read files, spy on the screen and plant furry porn in your home directory. That's literally what it means to be in group policy.

As I see it, the IT admins should be absolutely transparent with employees that all content touching the machine is subject to being recorded and have clear policies on whose approvals are necessary to go read the logs.

Re: MitM https proxies should be flagged too

[Anonymous Coward]

Riiight. I expose SSH host keys via DNS as well, doesn't mean your client is configured to use that. Multiply this by the billions of users and you realize why your suggestion is a false hope.

Re:MitM https proxies should be flagged too

[jellomizer]

Back in the 1990's I made a "Online ordering system" that was https but all it was a bash script CGI app once filled out the data it would send the order to the printer for the Admin to handle the order.

We just made sure people from outside the network couldn't packet sniff the message. Then everything else was unencrypted. Granted the paper print out didn't leave a digital database trail for remote access later on. The orders were just placed in a Real Folder.

Re:MitM https proxies should be flagged too

[Anonymous Coward]

Heh, we did something like that, too. Somebody probably had a patent on it, but we came up with the idea at a diner, observing cooks reading orders from a rotating carousel. We were just a bunch of drunk nerds wearing off our hangover at Lulus. Probably after a night of drinking, debauched sodomy, and injecting our nutsacks full of saline. Between the .bomb crash and my buddy Flipside going to the ER with a ruptured scrotum, that kind of ruined it though. I really miss those days, though.

Re:MitM https proxies should be flagged too

[Anonymous Coward]

All of this is pointless

Au contraire. Enforcing centralized authorization via CAs enables sites to be censored and taken down with the absolute minimum of fuss. See: Scihub. You don't even need to add the sites to a firewall. User's own browsers will do that for you.

Re:MitM https proxies should be flagged too

[Anonymous Coward]

On the other hand, those admins are defeating HTTPS security either by not blocking too much or allowing too much. (Maybe the browser knows that strange-signed certificate, maybe it doesn't. The proxy has no idea.) The original certificate must propagate to the browser for the security stack to work correctly.

Re:MitM https proxies should be flagged too

[Anonymous Coward]

My sysadmin handbook also mentions furry porn by name.

Re:MitM https proxies should be flagged too

[jaa101]

I'm sure there's an option to run Chrome with these warnings disabled. Any corporate IT capable of running a HTTPS proxy, requiring them to load an extra trusted cert on all their Chrome installs, is going to be able to activate this option. If Chrome lacks such an option it's just going to force companies to choose some other browser.

So, yes, Google's move is good for personal and small business users who just run with all the defaults. But they have limited power to force changes on large businesses with the IT budget to lock down their environment.

Re: MitM https proxies should be flagged too

[Richard Stalin]

What are the negative impacts of encryption?

1) Increased power requirements to perform encryption

2) Increased bandwidth requirements as caching servers are rendered moot

3) Automatic ability to identify you uniquely when using a service

4) Requires CA (Let's Encrypt helps, but modern HTTPS really does not promise who is on the other end anymore)

5) Most hosting services charge extra for HTTPS services and/or related additional resource use

6) Most of the "attacks" described could just as easily happen via malware, which is still an issue. This removes only one attack vector and even then incompletely (leading to false sense of security, see 4).

7) You are raising the cost of an information-only web site that offers no benefit to the operator and limited benefit to the user, but worse may cause the web site to effectively cease operation

8) You have created additional complexity for embedded devices that use an HTTP maintenance port

Re:MitM https proxies should be flagged too

[Anonymous Coward]

Don't forget the bad actors are using HTTPS. Many SOCs would be blind to the malicious traffic if the SSL decryption wasn't taking place.

Only low quality bots and malware are going to rely solely upon HTTPS to secure their communications. The bots and malware for sale on the darkweb are much more sophisticated than that. They will layer their encryption schemes so that breaking the first shell in their Russian doll of encryption layers will get you just about nowhere on the road towards analyzing their traffic. So this argument doesn't hold much water in my opinion.

Re:MitM https proxies should be flagged too

[chris-chittleborough]

Today I learned that "SOC" can stand for Security Operations Center.

Re:MitM https proxies should be flagged too

[ArsenneLupin]

Actually, the issue is much worse than just the admin being able to read intercepted https traffic.

These proxies make it possible for other rogue middlemen on the path to read the traffic too.

Indeed, as the corporate man-in-the-middle proxy is the only one to "see" the server's certificate, either he can blanket deny certificates that don't validate (such as self-signed, but with a fingerprint known and checked by end user), or blanket allow any certificate no matter how dodgy (seems to be the default behavior of most of these proxies)

Which means that third parties outside the company can spy on the traffic without any warning to show up anywhere.

Btw, a similar issue exists with those mobile apps that ask for your email password (social media, push notifiers, etc.): not only can the app's developer read and abuse your email, but so can everybody else who sits between the app developer's datacenter and your mail server, because typically these don't verifiy certificates before blurting your password over the line.

Re:MitM https proxies should be flagged too

[AmiMoJo]

The owner of Group Policy on a machine has (by definition) the authority to set HTTPs policies, read files, spy on the screen and plant furry porn in your home directory. That's literally what it means to be in group policy.

Literally what it means is that you only have to compromise one account to get 0wnership of the entire corporate network and everything on it.

Re: MitM https proxies should be flagged too

[Anonymous Coward]

9) Scaring people unnecessarily for data-only sites

10) Marching us toward "non-https" sites no longer will be loaded by Chrome ...first they came for a "not secure" icon...

Re:MitM https proxies should be flagged too

[Wrath0fb0b]

Actually, the issue is much worse than just the admin being able to read intercepted https traffic.
These proxies make it possible for other rogue middlemen on the path to read the traffic too.

They most certainly do not, unless the proxy is somehow losing confidentiality of the private keys corresponding to the issued certificates. But keeping key material confidential is a core responsibility of IT, across the board :-)

Indeed, as the corporate man-in-the-middle proxy is the only one to "see" the server's certificate, either he can blanket deny certificates that don't validate (such as self-signed, but with a fingerprint known and checked by end user), or blanket allow any certificate no matter how dodgy (seems to be the default behavior of most of these proxies)

Sure. A misconfigured proxy is Really Bad(TM). A properly configured proxy would not relay traffic unless the remote was verified. This is also core basic responsibilities of an IT department to configure stuff according to best practice.

Btw, a similar issue exists with those mobile apps that ask for your email password (social media, push notifiers, etc.): not only can the app's developer read and abuse your email, but so can everybody else who sits between the app developer's datacenter and your mail server, because typically these don't verifiy certificates before blurting your password over the line.

This isn't an issue with the mobile apps, it's an issue with boneheaded configuration on the backend not to verify TLS. This is basically a problem with any application ever deployed if it's set to ignore important security requirements.

Re:MitM https proxies should be flagged too

[Wrath0fb0b]

Yes, that is the design tradeoff.

You might be shocked to know that there is probably an IMAP server somewhere and if you compromise it, you get to read all the archived emails and impersonate email from anyone!

And a git server somewhere if you compromise it, you get all the source and the ability to impersonate commits from anyone.

Re:MitM https proxies should be flagged too

[Wrath0fb0b]

... balance between having situational awareness of what is going on in the network versus End User expectations of some privacy at work

I mean, the solution to expectations is to set expectations clearly, right? Whatever balance is chosen, the employees should be clearly informed about the policy, including what can be monitored/stored and whose approvals are necessary to read it.

Re: MitM https proxies should be flagged too

[Anonymous Coward]

Any policy other than "we reserve the right to monitor anything and everything" is asking for legal trouble.

Re:MitM https proxies should be flagged too

[nitehawk214]

Aha, I kept thinking "what the fuck does this have to do with System On a Chip?"

A google search for SOC was equally useless.

Re: MitM https proxies should be flagged too

[Wrath0fb0b]

Depends on the industry. Healthcare, definitely. Law, definitely. Others: YMMV.

There is no 68 version! (yet)

[Cronq]

Everyone writes about google chrome 68 released today but so far google didn't release 68 version. Just checked official google servers for google chrome (linux version). Stable is still 67.

Re:There is no 68 version! (yet)

[mykepredko]

Here is the release information - https://www.chromestatus.com/f...

I'm guessing it won't be released until later today (11:59PM UTC)?

Baked in financial transactions?

[Anonymous Coward]

I'm a big firefox lover but I also build websites, GIMME GIMME!

Re: Baked in financial transactions?

[Anonymous Coward]

Some of us remember when the web was for the interchange of ideas and knowledge, not some glorified shopping cart for mouth breathers.

Re: Baked in financial transactions?

[glitch!]

Exactly! eg. USENET:
alt.barny.die.die.die

Re: Baked in financial transactions?

[Anonymous Coward]

1. Web, not internet.
2. Logical chopping.
3. You missed the 'dinosaur'
4. If NNTP had been designed specifically to supply dinosaur death threats, you'd have a point.
5. I'm sure it wasn't.
6. Well, maybe.

celf signed certificates

[roman_mir]

For years I have been commenting on the way that browsers treat self signed certificates, it was always ridiculous and inconsistent. Sites with self signed certs were treated as if they were hacked by definition while HTTP traffic was not marked as insecure at all. At least at this point there will be some consistency to the way that HTTP and celf signed certificates are treated.

Re:celf signed certificates

[Anonymous Coward]

How do you feel about elf signed certificates?

Re:celf signed certificates

[roman_mir]

elf signed certs are fine, but they cause all sorts of issues in Gnome environments and Men in the Middle-earth attacks are possible.

Re:celf signed certificates

[omnichad]

I've heard of cert-signed ELF's, but not the other way around.

Re:celf signed certificates

[lgw]

elf signed certs are fine, but they cause all sorts of issues in Gnome environments and Men in the Middle-earth attacks are possible.

Whoever modded this down .... just needs to stop modding.

Re:celf signed certificates

[Anonymous Coward]

No, roman_mir, much like creimer and APK, needs to be downvoted into oblivion every time they show themselves around.

Re:celf signed certificates

[Dragonslicer]

Nobody modded it down. It currently has +2 Funny. The poster is just such an overwhelmingly obnoxious troll that all their posts start at -1.

Re:celf signed certificates

[roman_mir]

Trolls live in caves, supposedly in the day light they turn to stones. My posts start at -1 because the trolls run the asylum here.

Re:celf signed certificates

[Anonymous Coward]

You post at -1 because you are a pathetic cuck who worships (((Ayn Rand))). Go back to Russia.

To be honest

[bobstreo]

They're not wrong.

I'd be very concerned if any site I used for monetary purposes wasn't using HTTPS.

On the other hand, sites providing data services like streaming or news probably don't need to encrypt anything.

I mean it's not like the old days when you had to bolt on a hardware encryption module. HTTPS is pretty easy, and with modern processors not much of a burden.

Re:To be honest

[Anonymous Coward]

They're not right, either. It's security through cargo culting.

Re:To be honest

[XanC]

Do you not want any guarantees that your news is unaltered from the source?

Re:To be honest

[telek83]

Yes, I would like guarantees that google itself can't alter any content it sees fit to. This push is only so Google can control the ad space better, it gives them complete control over ads, as they can now see all of your HTTPS content, not just their own domain connections. HTTP is fine for non-input web pages, you can argue until the cows come home about intercepting raw HTTP and altering it all you want, because corporations MITM HTTPS anyway, so it would just as easy to do the same thing. Assuming the NSA is involved, I imagine they keys or permissions to keys, decryption would now be possible on a global scale, at least with self-signed certs this isn't possible unless they can obtain the keys. I for one will not bend to Google demands, I will warn the users flat out that the Chrome browser is no longer supported on any of my pages that do not require input.

Re:To be honest

[flink]

Do you not want any guarantees that your news is unaltered from the source?

Nobody is doing that. It's the source itself that is usually subverted.

Re: To be honest

[Anonymous Coward]

Actually, you probably want https just to stop your local ISP from inserting extra shit into your page.

Re:To be honest

[KixWooder]

Not news, but Comcast has and continues to modify websites.

Re:To be honest

[JesseMcDonald]

... you can argue until the cows come home about intercepting raw HTTP and altering it all you want, because corporations MITM HTTPS anyway, so it would just as easy to do the same thing.

Corporations can do that on devices they control because they have the necessary administrative access to install their own root certificates. Your local coffee shop or residential ISP can't MitM their customers' HTTPS traffic so easily, whereas the practice of tampering with pages served over HTTP is depressingly commonplace. This is far from theoretical; major ISPs have been caught red-handed injecting scripts and other content into web pages as well as splicing unique user IDs into HTTP headers for tracking purposes.

Short of banning HTTP from the web entirely, I would at least propose to restrict pages served over HTTP from any form of interactivity. No scripts, no plugins, no forms, no "responsive" CSS, limited media formats—no audio or video, just still images in a few well-vetted formats with ironclad decoders. Anything else is too risky to entrust to unauthenticated content. I'd also add a big warning banner above the page saying that the (human-readable) content of the page may have been tampered with and cannot be trusted.

Re: To be honest

[Zero__Kelvin]

What an absurd comment. Whomever created the browser has 100% access to everything, including your account logins and passwords, both http and https. Google gains no additional advantage.

Re: To be honest

[telek83]

Sure Google does, if we lock HTTP up Google gains a sizeable advantage. Anyone who is not part of the Google and friends can no longer inject ads into the page. While google can.

Re: To be honest

[Zero__Kelvin]

That is a complete strawman. Nobody is "locking up http" or anything of the sort. They are merely accurately indicating that http connections are not secure connections.

Re:To be honest

[Antique Geekmeister]

That has little, even nothing, to do with HTTPS. "Altered from the source" is occurring in such volume at the news agencies themselves that HTTP insertion is not even a significant issue.

It's business sites, where manipulation of order forms and prices can cause fraudulent orders, that man-in-the-middle abuse is the much larger risk.

Re: To be honest

[Anonymous Coward]

"Merely" indeed. They are putting big red warning signs on anything that isn't secure, which will naturally and understandably cause people to react negatively to and steer away from those sites.

I bet you think the Google shark is letting you into its mouth just to avoid the fishermen, too.

Re:To be honest

[thegarbz]

Do you not want any guarantees that your news is unaltered from the source?

Is it even relevant? Was it ever relevant? I meant wasn't it ever relevant?

Fuck Putin. I didn't say that. I said make love to Putin. Fake news!

Re: To be honest

[Anonymous Coward]

Worse, it lumps http connections into the same category as bad https connections, where something malicious likely was going on. The web isn't suddenly going to magically move away from http overnight, meaning people are being trained to ignore the warning signs.

Re: To be honest

[Anonymous Coward]

Or from your adblocking proxy from removing ads before it reaches ad-friendly Chrome.

Thanks Google!

[Anonymous Coward]

Thanks, Google, for breaking the internet.

Misusing your power (client & server) to push people around and to shape a landscape favoring your business and nothing else. You are finishing the nightmare Microsoft tried to realize.

Assholes.

Re:Thanks Google!

[squiggleslash]

I'm failing to see how an unobtrusive warning that the webpage you're looking at wasn't served securely is "breaking the Internet".

Re:Thanks Google!

[Anonymous Coward]

So much butthurt over an improvement with no downsides at all. Unless you work for the NSA and can't read everyone's internet any more. So sad!

Re:Thanks Google!

[Khyber]

The warning isn't fucking unobtrusive, that's the problem.

Any time you do something Google doesnt' like, it makes sure to make a big fucking fuss about it.

And that's going to give people the idea that the age they're trying to visit has been hijacked or otherwise when it has not.

It's going to pretty much result in digital libel and defamation of the site as idiots who don't know better start spreading word that "site x is hacked because Google Said So."

Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.

Re:Thanks Google!

[Anonymous Coward]

Indeed, a warning against insecure sites is much better than the "everything's ok alarm" situation you get with flagging sites secure.

Re:Thanks Google!

[dissy]

The warning isn't fucking unobtrusive, that's the problem.

They changed the "(i)" icon to now say "(i) Not Secure" just to the left of the URL in the address bar.

How is that obtrusive?

Do you consider the padlock icon with the words "Secure" equally as obtrusive?
They are now the exact same length as each other.

Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.

No, we just prefer to ignore assholes that make shit up that is demonstrably not true.

This is literally the change you are bitching up a storm about as "The warning isn't fucking unobtrusive"

Re: Thanks Google!

[Zero__Kelvin]

I hate when my age is hijacked!

Re:Thanks Google!

[Billly Gates]

I'm failing to see how an unobtrusive warning that the webpage you're looking at wasn't served securely is "breaking the Internet".

Dude I work corporate IT. Holy Crap will my phone ring off the phone tomorrow with HEEELLLP my intranet site is saying it is compromised! I probably will be working 16 hours a day without lunch telling everyone to use IE. Ugh.

Yes it does brink corporate apps and remember business use is part of the internet as well and is HUGE. This is unacceptable as no where in the IEEE standards does it say WWW must be encrypted by default.

Re:Thanks Google!

[Khyber]

Uh, no, how about a full-page warning going to http-only sites that are known-good yet Google classifies as 'dangerous sites?'

JUST got that going to an HTTP site (one used for looking up MIDI files.)

You apparently must be very new with Google and the internet in general despite your UID.

Shut your mouth until you're fully-informed on the subject. It is apparent that you're only about 10% informed. Good day.

Re: Thanks Google!

[Anonymous Coward]

Mandatory HTTPS does NOTHING AT ALL to prevent or even deter NSA mass surveillance.

Re:Thanks Google!

[thegarbz]

Thanks, Google, for breaking the internet.

Interesting comment. Note that I was able to read it and you were able to post it so it would appear the internet is doing just fine.

Re:Thanks Google!

[thegarbz]

The warning isn't fucking unobtrusive, that's the problem.

Of course it is. This change changed the title bar only.

If you're getting an intrusive warning it will be because the website you're accessing unencrypted is asking users to enter a password field unencrypted. You should inform the idiot who runs the website.

Google says you're welcome.

Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.

Take a chill pill man. Better still take some blood pressure medication. You'll blow an artery keeping this up.

Re:Thanks Google!

[thegarbz]

Shut your mouth until you're fully-informed on the subject.

He is fully informed. You're talking about two different messages for two different reasons. Frankly any website that asks to fill in a password field without encryption deserves a full page warning. Which is exactly what you got for your protection.

You're welcome mate.

Re:Thanks Google!

[Anonymous Coward]

Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.

Why don't you go and download more MIDI files about it Captain McNerd?

Re:Thanks Google!

[Rockoon]

The warning isn't fucking unobtrusive, that's the problem.

Nor have all of Googles "notices" been honest/

When I get poor bandwidth from Googles YouTube, Google always throws up a notice that my ISP is throttling the connection, when actually no Google my ISP isnt doing that and it is easy to find the cause of the problem: a major backbone is fubar at the moment.

Now call me silly but I tend to think that a major backbone being down is not cause for claiming that my ISP is throttling the connection, that IN FACT it is FUCKING EVIL to do what Google is doing.

Re:Thanks Google!

[Anonymous Coward]

I'm failing to see how an unobtrusive warning that the webpage you're looking at wasn't served securely is "breaking the Internet".

I doubt that's the only thing you're failing to see! !
It's not a bad thing to have HTTPS overall, I want to be clear on that. It's good, very good!! It's bad that the system of administration of CA authorities is centralized, it needs to be decentralized or else its little more than a protection racket as it is today.

RIGHT idea, WRONG implementation!

Re:Thanks Google!

[Anonymous Coward]

It's not like you hadn't been warned about that chrome 68 update something like 5 months ago, which means plenty of time to either reconfigure your web servers to use ssl, setup redirections and/or setup a reverse proxy with a valid ssl certificate to serve this unencrypted pages and eventually warn users about the "not secure" message.

Re: Thanks Google!

[Billly Gates]

We paid alot of money for our sites and even internet sites not working will give us call volume and makes us look incompetent if their internets are broken on a site we don't control

Re: Thanks Google!

[Anonymous Coward]

Mandatory HTTPS does NOTHING AT ALL to prevent or even deter NSA mass surveillance.

I'm so glad to hear that, NSA comrade! I'll be sure to reference your wisdom whenever someone in law enforcement complains about the "going dark" encryption problem, and tries to pass laws to ban default enabled encryption!

This is stupid garbage

[Anonymous Coward]

Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc.

Bbc.com doesn't need encryption. My business site which doesn't take payments or allow user accounts does not need encryption. It's a wall of text and pictures.

Google acting like the entire world needs this is incredibly stupid.

I already have to use Firefox to access firewalls because Google decided that "go to the site anyway goddammit" just means "allow traffic for 2 minutes, and then complain about the certificate again. And again. And again"

Now it's going to scare people for no reason. Screw them

Re:This is stupid garbage

[Anonymous Coward]

> Yes, bbc.com and your site do need encryption.

because?

Re:This is stupid garbage

[Vlad_the_Inhaler]

Come on - http://www.miketaylor.org.uk/tech/oreilly/truenut.html needs to be encrypted. Think of the children.
(any more cliches?)

Re:This is stupid garbage

[Anonymous Coward]

https://www.troyhunt.com/heres-why-your-static-website-needs-https/

Re:This is stupid garbage

[Luthair]

Insecure is an accurate description for HTTP. Further given the number of sites I've run into over the years showing locks and claiming to submit credit cards securely that are using HTTP I don't think this change is bad.

Re:This is stupid garbage

[Anonymous Coward]

That website is stupid garbage. I'm not watching a 20 minute video.

Re:This is stupid garbage

[Anonymous Coward]

Yes, bbc.com and your site do need encryption.

Probably want to use a vpn, too. You don't want everyone out there to know you are looking at big black cock all the time.

Re:This is stupid garbage

[Anonymous Coward]

Bbc.com doesn't need encryption.

You visit bbc.com. The great firewall inserts javascript to DoS attack another website.

You visit bbc.com. You read a simple article about foreign policy. In between you and the BBC, the text of the article has been replaced, changing your knowledge of facts, your opinion, and ultimately your vote.

You visit bbc.com. To preserve your privacy, you use a VPN or Tor. Your HTTP request has a BBC-UID cookie. Anyone snooping the connection can tell which link is yours as opposed to someone else's, and can track when you're there using the internet and which pages you go to.

You visit bbc.com. You're an activist in a country which would like to not have you around. Instead of receiving bbc.com, you receive child porn. It only takes a minute for the police to be signalled and break down your door and confiscate your computer. In court, experts testify that you hid the CP in a clever place (the browser cache). Not only do you go away for life, but you're discredited to the public and the court, police and experts don't have to be in on it.

Explain why it is essential to have bbc.com not be encrypted.

Re:This is stupid garbage

[Anonymous Coward]

Then RTFS? But based on the fact you didn't, I'm guessing that your rebuttal is that getting a certificate is too much extra work.

Re:This is stupid garbage

[omnichad]

All it said is whatabout man-in-the-middle. And if it's dry, uninteresting facts - who cares?

Re:This is stupid garbage

[omnichad]

They say "not secure" rather than "insecure." It's a fair distinction, that makes more sense in the context. The least of the problems are the wording.

Re:This is stupid garbage

[PhrostyMcByte]

Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc. Bbc.com doesn't need encryption.

Do you want your ISP to be able to see and use your browsing history? Do you want them to be able to block websites they deem inappropriate? Do you want Comcast to start injecting ads into websites like they've been caught doing before?

What if your bbc.com login is the same as your bank login? What happens when you get hit by one of those router worms that are popping up all over the place? Hopefully most people on /. will not have this issue, but I guarantee you that this is the case for most users.

Yes, Google has an ulterior motive. They want to knock your ISP out from being able to mine your data, to further their own monopoly. But as a whole... the change is still good for the user.

Re:This is stupid garbage

[Anonymous Coward]

jealous?

Re: This is stupid garbage

[Anonymous Coward]

Moron, it is a strawman. OP was implying that it should be up to the site operators whether they use HTTP or don't. If they don't and are MitM'ed, they are going to have a lot of incentive to force TLS. We do NOT need Google forcing their monopolistic agenda upon unsuspecting third parties.

Re:This is stupid garbage

[Anonymous Coward]

Troy Hunt is a fucking idiot

Re:This is stupid garbage

[Anonymous Coward]

What are the negative impacts of encryption?
1) Increased power requirements to perform encryption
2) Increased bandwidth requirements as caching servers are rendered moot
3) Automatic ability to identify you uniquely when using a service
4) Requires CA (Let's Encrypt helps, but modern HTTPS really does not promise who is on the other end anymore)
5) Most hosting services charge extra for HTTPS services and/or related additional resource use
6) Most of the "attacks" described could just as easily happen via malware, which is still an issue. This removes only one attack vector and even then incompletely (leading to false sense of security, see 4).
7) You are raising the cost of an information-only web site that offers no benefit to the operator and limited benefit to the user, but worse may cause the web site to effectively cease operation
8) You have created additional complexity for embedded devices that use an HTTP maintenance port

Re:This is stupid garbage

[Anonymous Coward]

> You visit bbc.com. The great firewall [wikipedia.org] inserts javascript to DoS attack another website.

This seems needlessly complicated. Why wouldn't they just mount a DoS attack directly using the firewall's networking capacity?

Re:This is stupid garbage

[Anonymous Coward]

To preserve your privacy, you use a VPN or Tor. Your HTTP request has a BBC-UID cookie.

I think it's important to correct a factual error here. An HTTP connection, when routed through a VPN tunnel, is just as opaque to an outside observer as an HTTPS session and arguably even more so since even with HTTPS that is not routed through a VPN they can still see where your traffic is going, to bbc.com, even if they cannot observe or alter the content. With the VPN tunnel the encrypted session to an outside observer appears to be between you and the VPN provider. Not only can they not inspect your traffic, but they don't know where it's ultimately going either unless they can monitor the outbound connections of the VPN server too and even then they won't know which connections are yours unless you are the only user of that VPN server. Of course, this won't stop determined and well resourced governments but at the very least it's a significant speed bump that drains their time and resources. If everyone used VPN services then even governments would have to be more choosy about who is worth spending time and resources to attack.

Re:This is stupid garbage

[Anonymous Coward]

The only people that can snoop his connection to the Internet are typically telecommunication companies putting court ordered intercepts in place.

What about joe random hacker? They're more likely to p0wn him using phishing or malware or crack his security camera that is on the internet. What's interesting (to them) is what's on your computer. All of the saved forms in your browser with your personal details. Snooping his surfing the bbc is worthless.

If you don't understand the evil of SSL/TLS and https then quite simply you haven't been burnt by Google deciding what protocols it will/won't support and finding out when you get to work that you discover that you can no longer manage the office printer.

If I want to browse the Internet insecurely, that's my business, not Google's.

What Google cares about is that it doesn't want anyone else snooping on all of its google-analytics traffic and cookies that it inserts in your browsing session.

Google doesn't give a rats ass about your personal privacy.

Google only cares about not giving away the value of its product (people using Chrome) to its customers (advertisers.) Embedded URLs in unencrypted HTML reduce the value of a web page to Google.

Re:This is stupid garbage

[thegarbz]

Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc.

People in the world are very much persecuted for what they read. It's not for you to decide their risk of viewing content.

Re:This is stupid garbage

[Anonymous Coward]

This seems needlessly complicated. Why wouldn't they just mount a DoS attack directly using the firewall's networking capacity?

This is not hypothetical. This happened.

We'll never know for sure why they did it this way. Maybe they're worried that DDoS software might leave fingerprints that the recipient could detect and distinguish from real browsers. Maybe attacking from your own IPs and your own AS# makes attribution easier and reveals (burns) the attacker's infrastructure. Maybe they couldn't afford the extra bandwidth or CPU to mount an attack on top of the bandwidth necessary to proxy all internet for a large country.

Re:This is stupid garbage

[Anonymous Coward]

My business site which doesn't take payments or allow user accounts does not need encryption. It's a wall of text and pictures.

Woah, stop the fucking press! I now want to know what unsavoury type of business you're running more than just about anything else in the World!

I can't even remember what story I'm commenting on, I am just so fucking intrigued about what kind of shitty right-wing grifting you're doing to scratch a fucking living!

I assume it's mugshots.com or some variation on that theme?

Re:This is stupid garbage

[Areyoukiddingme]

The only people that can snoop his connection to the Internet are typically telecommunication companies putting court ordered intercepts in place.

Given how very very many Cisco back doors and exploits are currently known, nevermind how many more are still unknown, ANYONE can snoop his connection to the Internet. And already has.

Re:This is stupid garbage

[Anonymous Coward]

Many years ago, Comcast sent me an new Wi-Fi router/cable modem. I didn't install it because I liked my old setup.

A couple months later, I started getting emails telling me to install it. When I ignored those, Comcast began intercepting Amazon web page responses and injecting javascript. The purpose of the javascript was to display a pop-up message warning me to install my router, or else. I saved the source for those pages -- I think I still have them.

So, yeah, everything does need to be encrypted.

Re:This is stupid garbage

[Areyoukiddingme]

You visit bbc.com. The great firewall inserts javascript to DoS attack another website.

You visit bbc.com. You read a simple article about foreign policy. In between you and the BBC, the text of the article has been replaced, changing your knowledge of facts, your opinion, and ultimately your vote.

You visit bbc.com. To preserve your privacy, you use a VPN or Tor. Your HTTP request has a BBC-UID cookie. Anyone snooping the connection can tell which link is yours as opposed to someone else's, and can track when you're there using the internet and which pages you go to.

You visit bbc.com. You're an activist in a country which would like to not have you around. Instead of receiving bbc.com, you receive child porn.

I would bet a pizza that Russian ISPs have done at least two of these things already, if not all of them. I would bet a second pizza that Russian ISPs did at least one of those things right now, as you're reading this. These are not theoretical attacks (except possibly the child porn dropper). They're actually happening in jurisdictions around the world. American companies created turn key equipment that can perform these attacks and sold them to anyone who could afford it.

Re:This is stupid garbage

[Anonymous Coward]

Thanks for pointing this out. I failed to clearly state the exact scenario I had envisioned.

Using a properly secured connection to a VPN, the attacker now needs to snoop the VPN<->BBC link, and gets only presence of traffic metadata from snooping the user<->VPN link.

The attack I had in mind was snooping the VPN<->BBC link, with multiple users all visiting the BBC through the same VPN. With HTTP the attacker could then tell the users apart by looking at their unencrypted unique identifier cookie, but with HTTPS they wouldn't be able to do that.

For that reason, I disagree with your comment "even [monitoring VPN<->BBC] they won't know which connections are yours unless you are the only user of that VPN server". The fact that any fingerprint exists is sufficient to make this possible. HTTPS alleviates this by encrypting nearly all the data making it much less likely to have any fingerprint. (Offhand, I think if you can fingerprint TLS clients used in the way the web uses TLS (i.e. no client certs) then you've found a serious flaw in TLS.) Let me know if I've misunderstood something!

As you rightly point out, VPN has the additional benefit of hiding which IP addresses you connect to. One of the downsides of a VPN service is that it is another party that has access to your traffic, to snoop or modify, whether on purpose or by being hacked themselves. Using HTTPS when you use a VPN means that you can ensure the your connect to the end point website is secure from the VPN provider. If the VPN is working well, it protects your IP, if the VPN itself is hacked then it's no worse than not using a VPN at all.

Re:This is stupid garbage

[martinfb]

There is a reason: money.
Would you like to buy some SSL certificates?

Re:This is stupid garbage

[Anonymous Coward]

What are the negative impacts of encryption?

I think the right question to ask is "what are the tradeoffs of moving to encryption?". The hardest part about designing a system for the web is that the costs are borne by everyone, while the protection offered needs to fit the most vulnerable person. There is no way for a browser to force the server to behave in a certain way, while the deployment of HTTPS almost exclusively benefits the browsers, not the servers.

To me, the situation is very clear cut, the benefits of universal deployment of HTTPS vastly outweigh the costs. I can understand and respect other people looking at the situation and coming to a different conclusion, but I want to make sure that the facts on the table are correct first.

My experience tells me that the most obvious approach to changing the cost equation, namely negotiating how much security is required in each a given context, will not work. The main limit is that people only defend against attacks they can imagine, and their five seconds of imagination is not as thorough as a billion dollar intelligence agency. Tapping all US backbones to snoop all internet packets and save them for future reference seemed wild until it was a well-established truth.

(Also, having more negotiation simply means more options which are less tested and more likely to be broken in ways we haven't noticed. Like IPSEC tunnels with a billion options that are easy to accidentally run insecurely even with a full team of experts vs. OpenVPN.)

I'll answer your examples point by point.

2) Increased bandwidth requirements as caching servers are rendered moot

This is the one argument against HTTPS by default that resonates with me. Bandwidth problems are real, and caching is important. Unfortunately caches are inherently in conflict with the confidentiality part of security. The cache has to see the response to store it and the cache has to see the request to check the cache. I think the current state of the art is that you can proxy your connection through the cache, if you choose to trust it. This only rules out transparent caches. Designs where either the server or the client has a cache it can trust are workable.

Maybe some day we can use fully homomorphic encryption databases to create caches that don't break the confidentiality guarantees, but that's strictly research material today.

3) Automatic ability to identify you uniquely when using a service

I'm not sure what you're thinking of here? What unique identifier does TLS have that HTTP doesn't? I would expect that encrypting more data means that there's less to use to fingerprint a client?

4) Requires CA (Let's Encrypt helps, but modern HTTPS really does not promise who is on the other end anymore)
6) Most of the "attacks" described could just as easily happen via malware, which is still an issue. This removes only one attack vector and even then incompletely (leading to false sense of security, see 4).

Ah, I see. It's a waste of effort to work on curing cancer because people can still die of AIDS. Even in the field of computer security, we can separate problems and solve them independently, even when there are other vectors that cause the same symptom.

If you think that CAs don't promise who's on the other end, I encourage you to demonstrate by standing up a server that responds with a valid cert for gmail.com. CAs are far from perfect, but they're also far from HTTP. There's policy enforced through audits (and even auditors can be distrusted, third point), and more recently there's technical enforcement too. If you make a gmail.com cert you either don't upload it to the CT log

Re:This is stupid garbage

[thoughtlover]

Google acting like the entire world needs [https] is incredibly stupid.

Not to mention Google can't even walk the walk... why are they delivering my search results via http and not https?

I have a feeling it's just a cashgrab to sell more certs, whether they or a business partner is doing it.

Re:This is stupid garbage

[Anonymous Coward]

> Explain why it is essential to have bbc.com not be encrypted.

Because when the CA revokes BBC.com's certificate, your browser won't let you read it at all.

Single points of failure

[Anonymous Coward]

More than half the websites in the world use Let's Encrypt certificates. Far too many websites use one of Google's script or font resources. Chrome's market share is approaching two thirds. Seven percent of all websites are accessed through Cloudflare's proxies.

Why encrypt LOLcats?

[XXongo]

I'd be very concerned if any site I used for monetary purposes wasn't using HTTPS. On the other hand, sites providing data services like streaming or news probably don't need to encrypt anything.

Yes!

for 90% of the stuff I browse on the web, I don't need https. I really don't care who sees the cat pictures I look at.

https should be saved for pages that actually need encryption

Re:Why encrypt LOLcats?

[Anonymous Coward]

for 90% of the stuff I browse on the web, I don't need https. I really don't care who sees the cat pictures I look at.

Because it's none of the NSA's or any other sniffing scumbag's damned business what you're viewering, full stop. If you only establish encrypted connections for things that you want private, then the snoops know what to focus on. If everything is encrypted, you offer them no clue.

Re:Why encrypt LOLcats?

[Anonymous Coward]

Right, there are plenty of still-valid pages that serve non-private data, and this is completely overlooking their existence (and these should not need to update to https because of the whim of some browser). Furthermore, if you begin showing people a warning for all these perfectly innocuous sites, you train them to ignore warnings (which are currently actually somewhat effective at helping idiots stay safe on the web).

Re:Why encrypt LOLcats?

[Anonymous Coward]

Honestly, I want encryption so my ISP *can't* inject adds into the pages. Need has nothing to do with it.

Re:Why encrypt LOLcats?

[willaien]

HTTPS isn't just about encrypting information like bank info - but also about preventing tracking. If all of your websites use HTTPS, your ISP can't snoop on your traffic to sell your data.

Re:Why encrypt LOLcats?

[willaien]

HTTPS also stops malicious routers (like at a coffee shop or something) from executing MITM attacks.

Re:Why encrypt LOLcats?

[nitehawk214]

https should be saved for pages that actually need encryption

But why?

Re:Why encrypt LOLcats?

[telek83]

It's about preventing tracking for anyone but Google*

Fixed that for you.

Re:Why encrypt LOLcats?

[Anonymous Coward]

> tracking

You just revealed how little clue you have.

I'm not concerned about my ISP tracking me. I'm concerned about Google (and whoever is in bed with them) tracking me. And given their ubiquitous tracking thingmajigs (Javascript, pixels, fonts, you name it), they'll succeed.

On the contrary, they are just making sure that *no one else* can milk their cattle. I'm *not* fucking Google's cattle.

Re:Why encrypt LOLcats?

[Anonymous Coward]

It's about preventing tracking for anyone but Google*

Fixed that for you.

I can choose not to use Chrome. (could use Chromium I guess.) I can choose to use NoScript, AdBlock, etc. to prevent Google from tracking me. (or lolhosts file)

But even if I thoroughly prevented Google from gathering data about my habits, I *can't* prevent my ISP from thoroughly tracking my activity over HTTP. I don't just want to opt-out of that kind of tracking. I want it to be impossible.

With HTTPS, that data is mostly opaque to them.

Re:Why encrypt LOLcats?

[Anonymous Coward]

https should be saved for pages that actually need encryption

But why?

Because he's either clueless, or living in the past; time has moved on and people have woken up to the fact that browser zero-days can be exploited through MITM as easy as piss when no encryption is being used! and to compound matters further, people (especially him) have forgotten about the likes of Phorm and NebuAd.

Re: Why encrypt LOLcats?

[Zorpheus]

The NSA still sees which server you connect to. And I think they also see the URL when you send it to the DNS server

Re:Why encrypt LOLcats?

[Anonymous Coward]

Thank you.

I've got a web site I use to store pictures so I can link them on sites I post on. Do I give a shit if my Transformers and Lego pictures aren't on an HTTPS server? Not one little bit. Steal them, post them willy-nilly, I don't care. And forcing me to upgrade to HTTPS means moving hosting services because my current service doesn't even provide it as an option. They're cheap, and they're reliable, but they aren't flexible.

This makes sense on any site I need to log in on, or any site I need to interact with. A site that's strictly static html and pictures? Don't care.

Re:Why encrypt LOLcats?

[Holi]

Use different DNS servers.

Re:Why encrypt LOLcats?

[Anonymous Coward]

That's gonna work until the ISPs require you to install their own CA on your computer.

Re:Why encrypt LOLcats?

[Anonymous Coward]

Ahhh there's the rub. Why would Google be so very interested in protecting your right to privacy? By pushing for TLS encryption by default, they've made tracking your steps across the web very difficult for parties that aren't inside the encryption transaction. But let's take a look at who IS inside that transaction:

1. You

2. The website you are interacting with

3. And...your web browser. Or Google, rather.

So now, all Google needs to do is collect your browsing data. And they most likely are since they provide the browser for you to use free of charge, though under the guise of protecting your privacy, they'll most likely remove any specific personalizing data and just leave generally identifying data (age, sex, general location, etc.). And if no one else can collect this information, Google can sell it for a fairly high price.

Re:Why encrypt LOLcats?

[willaien]

Why not take steps to prevent both from tracking you?

Re:Why encrypt LOLcats?

[willaien]

You could not use google's browser and still accept that https is important.

Re:Why encrypt LOLcats?

[tepples]

Some ISPs inject advertisement scripts directly into the port 80 TCP connection regardless of what DNS server is used.

Re: Why encrypt LOLcats?

[Zero__Kelvin]

Google has been doing what you are so afraid of for well over a decade and the sky hasn't come crashing down. Your fear is irrational.

Re: Why encrypt LOLcats?

[Anonymous Coward]

Oh, so Google *hasn't* built a trillion-dollar business centered around surveillance and advertising - an inherently parasitic and psychologically manipulative industry - and isn't now using it's huge reach and power to branch out into social engineering and mass behavioral control?

If the government was doing a tenth of the shit google is you'd grab the next plane to Montana and build a shack in the woods to live the rest of your life in.

Re:Why encrypt LOLcats?

[Anonymous Coward]

Troy Hunt has an excellent FAQ on why your LOLcats do need HTTPS: https://doesmysiteneedhttps.com/

Re:Why encrypt LOLcats?

[Billly Gates]

Yes they can. With the DNS cache they can track you and sell it to marketers and ads

Re: Why encrypt LOLcats?

[Anonymous Coward]

Tell that to all the dissidents who were disappeared because Big Brother Google ratted them out to a repressive government.

Re:Why encrypt LOLcats?

[johannesg]

It's still an utter mystery to me why this is even possible, given the draconian nature of copyright laws in the US. The webpage is copyrighted; the webpage with ads is therefore a modification of somebody else's copyrighted work.

Go ahead, try that with a work by (say) Disney, see how far you'll get. So why do ISPs regularly get away with it?

Re:Why encrypt LOLcats?

[thegarbz]

for 90% of the stuff I browse on the web, I don't need https.

You may not. Consider yourself lucky to live in a place where you can see the things you see without being persecuted for it.

https should be saved for pages that actually need encryption

The only person who is able to decide if they need encryption or not is the person doing the browsing. They cannot arbitrarily decide this since HSTS was widely implemented and since there's no longer a practical downside to simply serving encrypted information to everyone that is the safe default option.

Re:Why encrypt LOLcats?

[Anonymous Coward]

All pages need encryption. The first reason is that they run code in your browser, code that can be malicious. You absolutely want to authenticate that.

Re:Why encrypt LOLcats?

[fafalone]

Careful what you wish for. That would make adblockers copyright infringement tools, as they too modify the page.

Re:Why encrypt LOLcats?

[Anonymous Coward]

Not quite, advertisers on the page can still track. It's to avoid tracking by tracking by those on the network. Google don't have a monopoly on the tracking yet.

Far more importantly it's useful to stop ISPs adding extra adverts to the page.

Re:Why encrypt LOLcats?

[XXongo]

The only person who is able to decide if they need encryption or not is the person doing the browsing.

Right. But google thinks that the person doing the browsing should not be the one who decides if they need encryption, but instead that everything should be encrypted by default.

Re:Why encrypt LOLcats?

[houghi]

And not use the one from google. A nice one is 1.1.1.1 Also good for many countriesa where torrent sites are blocked.

Re:Why encrypt LOLcats?

[johannesg]

That's clearly personal use, while the other one is a for-profit activity on a commercial scale.

Re:Why encrypt LOLcats?

[Areyoukiddingme]

It's still an utter mystery to me why this is even possible, given the draconian nature of copyright laws in the US. The webpage is copyrighted; the webpage with ads is therefore a modification of somebody else's copyrighted work.

Go ahead, try that with a work by (say) Disney, see how far you'll get. So why do ISPs regularly get away with it?

Because no web site owner has been willing to be the test case. I suspect Comcast is careful not to intrude their injections into web pages from companies with enough money to fund lawyers for a decade, especially not American companies that big. Little guys, they can fuck all day long, and they know it.

I would dearly love to see someone file suit, especially someone with thousands of apparently independent web sites, so they could demand a trillion dollar infringement award. Unfortunately anybody serving enough URLs to Comcast customers to really hit them hard enough to hurt them for their misbehavior will be hurt by Comcast when they retaliate by blackholing all of said URLs so Comcast customers can't reach them (and otherwise degrading or damaging connectivity). The time to have filed that suit was when the Net Neutrality rules were in effect, so when Comcast reflexively tried to punish the one who filed suit, they could file a second suit for Net Neutrality violations. Unfortunately it's now legal for Comcast to retaliate against any content company filing suit against them.

Yet another reason why Net Neutrality is absolutely required for proper functioning of the Internet.

Re:Why encrypt LOLcats?

[JohnnyBGod]

But they usually don't. They usually just don't request some resources present on the page.

Re:Why encrypt LOLcats?

[thegarbz]

Right. But google thinks that the person doing the browsing should not be the one who decides if they need encryption, but instead that everything should be encrypted by default.

No. Google thinks they should give the user the required information that they are unsecure. Google thinks that admins shouldn't be deciding this for their users and should therefore take the safe approach without any practical downsides other than some extreme edge cases.

You can't close the barn door after the horse has bolted which is how accessing HTTP works now.

would be silly to encrypt public stuff but...

[Anonymous Coward]

Now with the end of net neutrality. Your ISP might soon start adding adds to your content if it isn't encrypted.

Re:would be silly to encrypt public stuff but...

[Anonymous Coward]

Yes, Google is protective of their ad revenue, https = no ability for ISPs to provide targeted ads without encouraging websites to incorporate their own web tracking scripts or promoting their own search engines.

This is to prevent ISPs from ad injection

[Anonymous Coward]

The real reason behind this move is to secure Google's ad revue. If everything is HTTPS then nobody in the middle can inject or alter HTML ads into your browsing experience. This is the same reason why Chrome uses Google's DNS server 8.8.8.8. If you type in a non-existent domain google wants to redirect you to a google search page, rather than something ISP's DNS server will direct you to. The more Google can control your browser front end experience, and where you are going, the more control they have over the Internet. Security for the user in this case is just a side affect.

Is this like DRM?

[ripvlan]

I have to wonder if we lockup all websites as viewable only via SSL - does that limit access to anything (historical) ? Alright - time to through away the crap, we can't keep everything.

Why is bbc.com insecure because it uses HTTP? I understand why mybank.com would be insecure. I'm worried well lose something valuable when Chrome et al block (some day in the future) all of HTTP.

Besides - it's only a matter of time before hackers move to SSL attacks. When the low hanging HTTP fruit is all gone, SSL looks very appetizing.

     

Re:Is this like DRM?

[willaien]

It's not just about securing the data in transit, it prevents tampering (eg. ISP or router injected ads) and tracking (your ISP cannot know what you visited on the site, just that you visited that particular ip and domain)

Re:Is this like DRM?

[Dragonslicer]

I have to wonder if we lockup all websites as viewable only via SSL - does that limit access to anything (historical) ?

It would only affect servers where the admin is doing just barely enough maintenance to keep the site alive. HTTPS doesn't affect scripts running on the server, page rendering, etc. The content is not affected in any way, and really the only reason that anything at the application layer even needs to know about the encryption is because it has to listen/connect on port 443 instead of port 80.

Re:Is this like DRM?

[AHuxley]

More a way to keep ads secure per trusted site. Data to and from the browser. The browser has to trust approved ads for the site they use https with.
See the site, get the approved secure ads.

Re:Is this like DRM?

[jythie]

I already run into problems with one of my NASes. Even if something uses HTTPS, the cert can be old or 'outdated' which Chrome can really complain about, sometimes not even giving you the option to view anyway. Really annoying for embedded devices that you don't replace constantly.

All the better to control you with, my dearie!

[Anonymous Coward]

This is just Google making sure you HAVE to see their ads.

Google is the company that used to claim they wouldn't be evil. They quite publicly gave up on that.

Re:All the better to control you with, my dearie!

[Anonymous Coward]

Wait, you're saying that the Internet should be designed to allow a hacked router to replace ads that pay the site, with ads that pay the hackers? Instead of, say, running an ad blocker on the client? And you're willing to sacrifice the security and privacy of the whole web-using population to enable this?

You shouldn’t have given Chrome market share

[xack]

Now Chrome can do web controlling actions like security extortion. the next step will be making only google approved certificates complete with extortionate prices will be marked as secure. Join the resistance, get one of the xul trio of browsers Waterfox Pale Moon or Basilisk.

I mean this is good and all, but...

[Anonymous Coward]

in their recent versions, I've seen this break many intranet sites behind all kinds of VPNs and firewalls, forcing you to have to go through the pointless exercise of confirming the exceptions every single time.

Don't you mean...

[Anonymous Coward]

I think you mean Self cyned sertificates.

The problem:ALL HTTPS is insecure and allows MitM

[Anonymous Coward]

The entire concept of certificate "authorities" is already fundamentally broken by design. (Kinda obvious, given the "argument from authority" fallacy.)

I can not trust an organization that happens to host a website, but I'm supposed to trust an organization that happens to be a CA? Because the browser maker said so? Whose trustworthiness is not established either, by the way.

If you want at least some trust, you either have to BE the CA (like with my own servers), or meet and get to know the person *personally*. Everything else is just hearsay, and of comparable trustworthiness to whatever you receive when you send out an unencrypted HTTP request to a random unknown domain.

Web engineering

[Anonymous Coward]

By social engineers.

"Redirect"

[darkain]

Their metric specifically mentions redirecting. One of the sites that I manage is an antique auto parts store. There is still a large fraction of our customers using Windows 98 era PCs. Due to this, automatic redirects from HTTP to HTTPS are disabled, so they can still browse the catalog and call us on the phone to order. Bots testing this site would notice the lack of redirection. However, modern browsers pass in some new additional headers which mention some HTTPS capabilities, and *IF* these headers are available, automatic redirection happens (since we know the client will be on a browser which supports the proper TLS version)

I'm sure several of these other sites are using a similar approach. I just personally tested FedEx.com, and it is properly redirecting from HTTP to HTTPS in an up-to-date browser. So odds are that these bots testing these sites are not fully supplying all the same headers that browsers do.

Re:"Redirect"

[MassacrE]

Windows 98 Era PCs on the internet? I am shocked that is even possible!

I've seen unpatched windows xp machines completely break down due to the volume of competing viruses on them, and forgetting the open networking they haven't gotten a modern browser update in what, a decade?

Re:"Redirect"

[omnichad]

Due to this, automatic redirects from HTTP to HTTPS are disabled,

You can check the user-agent string before redirecting and still secure the majority and protect moderately aged browsers. And the rest should be warned heavily what risk they are under.

Re:"Redirect"

[Scoth]

Last version of Firefox that runs on Win98 is in the 2.x series, without some third party hack like KernelEx, which these people aren't likely to be running. So yeah, a little over a decade.

As long as they're behind NAT they're probably safe from a lot of the immediate remote exploits. XP was kind of a mess because it was still in an era when people connected to the internet directly with public IPs on individual computers with no firewalling at all, whereas these days most people are at least behind some kind of NAT. From my messings-around with FF2 I'd be surprised if they were actually able to accomplish enough on the www with it to get infected with anything. Plenty of stuff still kinda works, but mostly it'd be completely broken. Windows 2000 will run at least Firefox 12 officially, and a few later versions with a little bit of tweaking, but still old enough to not run especially well on the modern web.

Re:"Redirect"

[Khyber]

"I've seen unpatched windows xp machines completely break down due to the volume of competing viruses on them"

What are you considering "unpatched?" After SP2 (it went up to 4 in XP) the system is rock-solid. Looking at two XP systems right now on the internet, not giving a fuck - my laptop and one of my legacy desktop systems.

Re:"Redirect"

[Anonymous Coward]

Their metric specifically mentions redirecting. One of the sites that I manage is an antique auto parts store. There is still a large fraction of our customers using Windows 98 era PCs. Due to this, automatic redirects from HTTP to HTTPS are disabled, so they can still browse the catalog and call us on the phone to order. Bots testing this site would notice the lack of redirection. However, modern browsers pass in some new additional headers which mention some HTTPS capabilities, and *IF* these headers are available, automatic redirection happens (since we know the client will be on a browser which supports the proper TLS version)

I'm sure several of these other sites are using a similar approach. I just personally tested FedEx.com, and it is properly redirecting from HTTP to HTTPS in an up-to-date browser. So odds are that these bots testing these sites are not fully supplying all the same headers that browsers do.

Antique auto parts. For Antique Cars. Which are usually the exclusive hobby of wealthy people. They use horribly non-secure operating systems. So what you're saying is hackers could make websites targeting these wealthy schmucks and steal all their money?

Re:"Redirect"

[toddestan]

Windows 98 nowadays would be security through obscurity. It's different enough from the NT line that most attacks on XP and later simply aren't going to work on it. The number of Windows 98 machines on the internet is small enough that no one is going to bother targeting them. I still wouldn't do it, but you would likely be safer now than you would have been 15 years ago.

Re:"Redirect"

[MassacrE]

They were primarily acquired via Java and Flash through IE, IIRC. I don't believe IE was sandboxed until Vista.

You lost against your own argument. ... *STABLE*!

[Anonymous Coward]

But there is an unstable version. Which, if it is anything like most open source software, is already quite stable.

Re: something something motes and beam

[nitehawk214]

The text on duck.com is significantly more informative than I expected.

Not what the web was made for

[DogDude]

This kind of silliness wasn't what the web was designed for. The web was designed for the free dissemination of free information. Encryption and security are bolted-on hacks that not only don't work very well, but aren't at all in keeping with the original intent of the Web (or the whole Net, for that matter).

I don't see any reason most web sites need to be encrypted.

Re:Not what the web was made for

[Ksevio]

Encrypting the material in transit doesn't make any less freely disseminated or the information less free. The access is suppose to be open, not snooping on other users. Maybe you're still running Lynx or something, but encryption and security are fairly well developed these days and work great!

Re:Not what the web was made for

[Opportunist]

Back when the web was designed, it was filled with engineers and technogeeks whose interest in information was one where your status and "street cred" depended on the value and veracity of your information.

In the current time of fake news, lies and deceit, your status depends mostly on how many people you can dupe into hating your opponent in any way possible because you yourself don't have any positive traits either, so you have to get people to hate the other guy even more.

In this climate, yes, I DO want to be able to verify that the information I get is from the source I wanted to get it from and has not been tampered with in transit.

Bollocks

[Anonymous Coward]

There are some plenty of internal-only web sites that have zero need to be encrypted (for many reasons) that are going to be if theyâ(TM)re not already by this Google âoesolutionâ to an overstated problem.

Re:Bollocks

[Ksevio]

Well if it's the type of site that doesn't need to be encrypted for some reason then it's probably not a big issue that it says it's not secure.

finally. HTTPS forever

[Anonymous Coward]

some of my developers friends still don't redirect from http to https on any platform
or language even though we have perfectly constructed handlers for this job.

is it me or just lazy developers?

i redirect if https is available

Software updates etc...

[Strider-]

Hopefully, though, software updates (such as Windows Update, Apple Update, etc...) will remain unencrypted. I run a network that services some remote communities via satellite, and those things are eminently cacheable (we have a WSUS server for our corporate computers).

Before you get your panties in a twist about that being insecure, the way I recall these things working is that the update client fetches SHA256 sums of the update files via HTTPS, and then downloads the files over HTTP. That way, the updates can be cached locally, but the end user can still be assured that they haven't been tampered with.

Re:Software updates etc...

[Anonymous Coward]

I have a similar situation and the decline in utility of caching proxies with HTTPS is a nightmare. If we could get plain text with signatures instead of encryption for non-input websites (like with software updates), everything would be great -- it would be cacheable but unalterable -- but this is just a nightmare for those of us who have to deal with low-bandwidth and/or high-latency links.

Re:Software updates etc...

[Anonymous Coward]

I think my ISP does caching of my Debian updates. There is a marked difference in speeds downloading from the unencrypted security.debian.org or ftp.us.debian.org in the morning or a week later vs. the evening or a day later.

Re:Software updates etc...

[vtcodger]

"but this is just a nightmare for those of us who have to deal with low-bandwidth and/or high-latency links."

Quite clearly folks like you do not belong on the modern internet which is being designed by the greatest geniuses in human history to perfectly satisfy all legitimate needs.

You and your motley friends should pack up your kit and leave.

And yet for every year of its hayday

[Anonymous Coward]

You had security luminaries telling you XP was essentially unhackable. Ed Bott being the loudest luminary.

internal apps / IPMI's don't need certs

[Joe_Dragon]

internal apps / IPMI's don't need certs so why push this?

Crying Wolf

[nuckfuts]

The upshot of this is that users are going to become accustomed to ignore all such warnings and proceed to the site anyway. Rendering even legitimate warnings basically useless.

Re:Crying Wolf

[Anonymous Coward]

These warnings were never legitimate, they attempt to place warnings up for self signed certificates as though it was a hax0r attack and scare the hell out of people. In truth they just wanted to market SSL certificates for 600$ a pop because it was a lucrative industry for awhile. A self signed cert is not entirely safe from MiTM attacks it does however provide an encrypted channel for communication and as such should have less of a warning than a pure http site.

They still try to scare the hell out of people about self signed certs even though the industry for them is nearly gone.

Re:Crying Wolf

[nuckfuts]

There are multiple reasons why a certificate might trigger a warning. Being self-signed is only one of them. Another reason is when the server name on the certificate does not match the URL you typed in your browser. That is one example I consider a legitimate warning, and one that a user might just ignore if they become conditioned to just click "proceed".

Re:Crying Wolf

[Opportunist]

I can see why you posted as AC. I, too, wouldn't want my name attached to this display of ignorance.

Re:Crying Wolf

[thegarbz]

The upshot of this is that users are going to become accustomed to ignore all such warnings and proceed to the site anyway. Rendering even legitimate warnings basically useless.

Given that all that is happening is websites which are insecure will be listed as such, this isn't a warning as much as it is actual information relevant to the session.

The only warning users may get is if they visit an insecure website that asks for login details. There's only so much you can do to defend a user from themselves, but the end goal here is not about the users as much as it is about the web masters.

ROFL

[Anonymous Coward]

The page at Fedex.com where you pick your country is not encrypted IF you have not been there before. After you pick a country it redirects to HTTPS .

Oh. My. God. Somehow might sniff out what country I am in!

LOL, If someone if sniffing out my connection they already have an IP address that gets it to the state level. Silliest complaint ever

Comment removed

[account_deleted]

Comment removed based on user account deletion

Encryption isn't the point

[chubs]

SSL does more than simply encrypt traffic. The biggest benefit of SSL for static web sites or information-only websites is that you can verify that you are connected to the right source. Some people mentioned content tampering and man-in-the-middle attacks, but what about a good old fashioned DNS cache poisoning? With SSL, you're not as susceptible to that type of attack.

Re:Encryption isn't the point

[chubs]

I do realize that DNS cache poisoning is often a means to an end to get to man-in-the-middle attacks, but the two are separate and warrant being talked about separately. With MITM attacks we often talk about surveillance and tampering, so we often talk about encryption and content validation, while we ignore the issue of source validation. I need to be sure not only that my data is unchanged, but that it came from who it claims to come from. The biggest benefit of SSL is CAs, from that perspective.

It makes sense

[Anonymous Coward]

This is just a different icon, and a warning message. Many things done by goggle Chrome break my workflows and cause extra work, but a warning I can live with. The sites are indeed less secure than ones with self signed or invalid certs. Maybe users will get that "insecure" isn't bad for everything.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

"Mandatory Encryption" Disable?

[Anonymous Coward]

Hi all,

If this is supposed to have been a recent thing......I must have had a bleeding-edge beta version of this crap (on work pc, so it actually may have been a possibly policy set by over-protective / SCARED windows IT administrators?) 'Cuz this has been happening since.... around christmas at LEAST.

Either way. Here's the question I have for any of you:
Does anyone know an easy way (as in registry key, chrome setup registry or whatever that advanced options/configuration thing is) to disable redirecting (as soon as a http:// is entered, it replaces http with https on ANY url input)?

Not necessarily just for here at work....but I ran into the same thing on a PC running windows 10 with a recent browser and NEEDED to sniff (using tcpdump) web traffic to reverse engineer a poorly written web viewer application for a very early web-viewable camera (it was a "box camera" type thing, but with an ethernet port where the BNC video out port should have been...)

I personally don't install new web browsers unless I have to. And to this day, most sites work fine without issue using a VERY old browser that was based on Mozilla/firefox (it's called k-meleon), the only issue I usually see if there's an issue at all is the "YOUR BROWSER IS OUTDATED!" message. I ignore that b___s__t like any other person from the oldschool. I still run a p3 1000mhz w/ 512 mb ram, with the same install of XP that I had on it in 2005. And it boots up (from an off state) faster than most people's computers running recent versions windows (I'm not joking, probably YOURS too!). I've got tons of more recent hardware, but I'm not sold on it actually being that much faster for what I am using it for.

Thanks !

How about a compromise

[sjames]

How about Chrome finally taking my word for it when I tell it I trust a particular cert even if it isn't officially signed by some entity I have never heard of.

Meanwhile, if it's so important, why do they make it a pain in the ass for me to examine the cert used by a site? Shouldn't it be in the menu that drops down when I click on the lock icon?

For that matter, why isn't it easy for me to tell Chrome that I do NOT trust a given cert no matter who signed it or that I don't trust a particular CA to sign off on water being wet?

Re:How about a compromise

[Ksevio]

How about Chrome finally taking my word for it when I tell it I trust a particular cert even if it isn't officially signed by some entity I have never heard of.

The vast majority of users shouldn't be doing that. There are some exceptions (such as for developers), but Chrome should cater to the larger number even if it inconveniences the tiny a minority a little if it means greater security.

Meanwhile, if it's so important, why do they make it a pain in the ass for me to examine the cert used by a site? Shouldn't it be in the menu that drops down when I click on the lock icon?

Click the lock, click "Certificate" works for me

For that matter, why isn't it easy for me to tell Chrome that I do NOT trust a given cert no matter who signed it or that I don't trust a particular CA to sign off on water being wet?

Not a highly requested feature

Re:How about a compromise

[sjames]

Developers, admins, people using a private webmail, etc. In those cases, I know with greater certainty that I have the correct un-intercepted site than if a CA signed it. The option exists to temporarily accept the cert, why not be less of a pest? But make it equally easy to stop trusting the cert.

Click the lock, click "Certificate" works for me

It's not there, I just tried it. It used to be there once upon a time.

Re:How about a compromise

[tepples]

The vast majority of users shouldn't be doing [accepting certificates from an unknown issuer]. There are some exceptions (such as for developers), but Chrome should cater to the larger number even if it inconveniences the tiny a minority a little if it means greater security.

You said home users shouldn't accept certificates from unknown issuers, and Let's Encrypt doesn't issue certificates for names in non-public TLDs. So what certificate should be used instead for a private HTTPS server on the home LAN, such as the configuration page for an Internet gateway or network printer?

Re:How about a compromise

[Anonymous Coward]

On what platform? I'm using v68 (x64) on Windows 10, certificate is definitely still present. Notably, it displays the native Windows certificate dialog, so I wouldn't be surprised that the feature might not be present on some platforms where they might otherwise have to implement their own certificate dialog.

Re:How about a compromise

[sjames]

On linux, you have to right click->inspect->security->view cert. They clearly have a dialog for it, they should make it available without drilling down 4 levels into a developer tools menu.

Re:How about a compromise

[Ksevio]

Guess it's a linux thing

Re:How about a compromise

[Ksevio]

You'd probably want to install the certificate on the machines connecting to the LAN services

Re:How about a compromise

[sjames]

It's a chrome thing when chrome is on Linux. If they can display the information anywhere, they can display it somewhere more relevant or convenient.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re: And I think they also see the URL when you sen

[Anonymous Coward]

"And I think they also see the URL when you send it to the DNS server"

Aaaaand someone doesn't know how DNS works. The only thing sent to a DNS servers is the *Domain Name*. It's called the Domain Name System for a reason.

Comment removed

[account_deleted]

Comment removed based on user account deletion

HTTPS is centralizing the internet

[SkOink]

I'm all for encrypting web traffic, but this push for HTTPS-everything is kind of terrifying. It puts us in this dystopian future where we rely on CAs to decide whether or not we can visit a website.

If a couple of CAs decide (or are told) to revoke my cert, there's literally nothing I can do about it. And all of a sudden my website is inaccessible to 90% of browsers, and there's nothing I can do about it.

I would happily support some kind of peer-to-peer encryption scheme (HTTPS with no CA, maybe). But centralizing everything through CA gatekeepers is just asking for a government to butt in.

Re:HTTPS is centralizing the internet

[Opportunist]

A revoked certificate isn't much different from a self-signed certificate. You can still connect to the server, there is just no guarantee that you're actually talking with the correct server. Which is something you kinda need someone to vouch for unless you want to manually verify every certificate of every server you communicate with.

Re:HTTPS is centralizing the internet

[SkOink]

That's logically true, yeah - but browser UIs make it increasingly tough to accept self-signed certs. Tough enough that my grandma wouldn't be able to figure it out. Which effectively makes a revoked cert into a death sentence for a website.

Re:HTTPS is centralizing the internet

[Anonymous Coward]

Gopher.

Re:HTTPS is centralizing the internet

[Anonymous Coward]

This is actually the plan, to control whether you are permitted to have a website.
Google is working with various governments to introduce these measures for this reason alone.

Re:HTTPS is centralizing the internet

[toddestan]

That's true with browsers like Firefox. I just tried Chromium with a site with a self-signed certificate, and it simply refuses to connect at all.

Re:You shouldn’t have given Chrome market sh

[Anonymous Coward]

Do any of those browsers implement DNSSEC DANE TLSA mode 3?

The first web browser that does will finally win this war of nonsense and bring real security to the landscape.

Too many warnings = people ignore warnings

[raymorris]

The number one reason, from my experience, is that of people see warnings a lot, especially for dumb things, they are quickly trained to ignore warnings. Microsoft learned this lesson with their first attempt at UAC. SELinux had a similar problem for a few years.

For best security, you should alert people to actual security problems, and only problems they can do something about. Reading Wikipedia over http is not a problem.

Also, Bobmorning makes a good point here:
https://tech.slashdot.org/comm...

The security systems that are supposed to rpotect you can't see all the malware being downloaded onto your system, the data being exfiltrated, etc when everything is TLS.

Lost trust - lost their CA. Kinda proves the point

[raymorris]

BTW you made a very good point in this other post, though I don't think most people have the background knowledge to fully appreciate your point.
https://tech.slashdot.org/comm...

> They had to divest themselves of the CA business because they prove themselves repeatedly to be not trustworth

Symnatec couldn't be trusted, therefore they couldn't have a CA business. That seems to indicate that untrustworthy companies can't be CAs (for long).

All News Must Be Registered

[Anonymous Coward]

This isn't about security. It's about making sure that only registered publishers put material on the internet.

You think that is the main feature of https?

[fuzzyf]

Your mundane page showing cat pics or whatever can be a serious threat if the script-kiddie on the next table can inject whatever javascript he wants into it before you receive it.

Yes, a source can be compromised too, but the ease of mitm http is just amazing. Also, any http security header (csp, hsts, hpkp, etc) or other mitigation techniques are futile if transport can't be trusted.

This is true

[raymorris]

I suspect most people reading this haven't worked in a SOC, so they won't appreciate how much truth there is in what Bobmorning said.

> There is a delicate balance between having situational awareness of what is going on in the network versus

Exactly. We have systems that can see when a site is trying to do a drive-by malware installation or whatever, lots of ways to protect people in some pretty advanced ways. We can't protect what we can't read, though. So there is a balance. Encrypting everything makes it easier for the bad guys to send bad stuff to and from your machine without getting caught. So the ideal is neither "encrypt nothing" nor "encrypt everything as if it's a state secret". The best ways to protect against various attacks are situation dependent. For reading Wikipedia, unencrypted is probably safer overall. It's also faster - https can't be cached.

Re: This is true

[Anonymous Coward]

For reading Wikipedia, unencrypted is probably safer overall. It's also faster - https can't be cached.

Not if you're worried about dragnet surveillance. Regardless of whether you're afraid of e.g. your ISP selling info about what medical symptoms you've been reading about to insurance companies, or you're afraid of the government putting you on a no-fly list for being a bit too curious about chemistry and Islam, Wikipedia is one of those things I'd encrypt first. And I don't care if it's not cached, I think privacy is worth a slightly higher latency.

Re:This is true

[arglebargle_xiv]

My feelings exactly. They're pointing out that the BBC isn't encrypted. That's because the task of the BBC is to disseminate news in the most easily-accessible format (radio, TV, the web), not to protect nuclear weapons launch codes. And then there are the bazillion web sites that aren't mentioned, knitting patterns, cat pictures, gardening advice, cake recipes, that need exactly zero encryption but that are now being held ransom to some braindead agenda that someone at Google has.

Re:The problem:ALL HTTPS is insecure and allows Mi

[Anonymous Coward]

That is why I liked the Perspectives Project, where they had "notaries."

When faced with a certificate, you would ask the notaries for the cert they thought you should have, they would get the cert from the page, and send it to you. You would then compare the certs from several notaries to your cert, if enough of them matched, it would be considered good. You got to control what percent needed to match (100% was an option). The idea was, that either your cert was good, or the entire internet was pwned as far as that site was concerned, the idea was that if everyone had a bad cert for the internet, the site would eventually notice.

What certificate for home HTTPS?

[tepples]

I would at least propose to restrict pages served over HTTP from any form of interactivity. No scripts, no plugins, no forms, no "responsive" CSS, limited media formats—no audio or video

Under your suggestion, with what certificate on what domain should the operator of a private video server on a home LAN run HTTPS? Public CAs don't sign certificates for RFC 1918 private IP addresses or for names within non-public TLDs (such as .local used by mDNS). Some users have suggested using dynamic DNS, but in order to qualify for a certificate from Let's Encrypt, a subdomain needs a TXT record, and the domain it's under needs a Public Suffix List entry. Many dynamic DNS providers don't support those.

All domain owners qualify for LE cert

[tepples]

It's about making sure that only registered publishers put material on the internet.

I don't see what practical problem that causes for publishers on the Internet, seeing as Let's Encrypt allows anybody who owns a domain name to register as a publisher without charge. Or are you anticipating tighter control of domain names in the first place?

Re: All domain owners qualify for LE cert

[Z00L00K]

Either that or a tighter control of CAs where you need to pay a considerable sum each year for a certificate for your site.

Re: All domain owners qualify for LE cert

[tepples]

I don't see how increasing the price of TLS certificates fits into Google's plans as long as Google's Chrome division remains listed on LetsEncrypt.org as a sponsor.

Re: All domain owners qualify for LE cert

[Anonymous Coward]

considerable sum??!!?? Its just $10US for a 12month cert.

Secure Contexts

[tepples]

W3C maintains a spec called Secure Contexts, which encourages web browsers to completely disable certain sensitive JavaScript features within HTML documents served over a cleartext HTTP connection. Only HTTPS and http://localhost/ are allowed to use Service Workers, Geolocation, Payment Request, Presentation, and several other web platform APIs.

Re:Secure Contexts

[Anonymous Coward]

W3C maintains a spec called Secure Contexts, which encourages web browsers to completely disable certain sensitive JavaScript features within HTML documents served over a cleartext HTTP connection. Only HTTPS and http://localhost/ are allowed to use Service Workers, Geolocation, Payment Request, Presentation, and several other web platform APIs.

And it's as dumb as early browsers trusting SSL. Seriously. Wayyy before we had certificate pinning, dnssec or hell browsers that even checked the auth chain so long as you served your payload over SSL the browser assumed you were more trust worthy.

There needs to be a "fuck off" option to js. There is absolutely no reason to enable most of the crap we have now by default (battery status, access to gps, usb, vr, etc). TELL me when sites need it don't assume I want you giving it As it stands now you can't even tell when SSL has problems with a request. Try it. Untrust a few CAs and if you're lucky enough to find a site that isn't forcing HSTS (which you can't override), but has requests to other servers (sayy... a.fsdn.com), you'll have no idea why slashdot isn't rendering properly. The only way to tell is either looking at uMatrix/uBO's console or in the rare event it generates an error in the browsers console. You have to visit the site manually to accept the friggin ssl cert which is now temporary by default. Cookies are the same way, you no longer get a prompt

It's nice that Google has their own CA to issue as many certs as the want on the world but in reality there are MANY cases where we simply won't certify products on their browser.

Re:Secure Contexts

[tepples]

There is absolutely no reason to enable most of the crap we have now by default (battery status, access to gps, usb, vr, etc). TELL me when sites need it

Many of these sensitive web platform APIs, such as location and notifications, already require the user to interact with a permission dialog presented by the browser before a script in a document can use them.

ISP caught injecting cross-site scripting

[tepples]

Comcast has been caught injecting advertisements into HTML documents that Comcast customers view over cleartext HTTP. If BBC doesn't want Comcast performing cross-site scripting on BBC's site, BBC needs to use HTTPS.

Google sponsors Let's Encrypt

[tepples]

google approved certificates complete with extortionate prices

Let's Encrypt offers TLS certificates to domain owners without charge. Its website lists the division of Google that maintains Chrome as a sponsor. So no, I don't see Chrome requiring "extortionate prices" for TLS certificates any time soon.

Let me know when registrars bundle DNSSEC

[tepples]

Do any of those browsers implement DNSSEC DANE TLSA mode 3?

Do any websites use DNSSEC DANE TLSA mode 3, with which to test experimental web browsers that do support it?

Many domain name owners use the zone hosting bundled by the registrar, and in a lot of cases, DNSSEC is either unavailable or an upsell at an additional recurring fee. Let me know when most major registrars' bundled zone hosting supports DNSSEC by default. Only at that point will DANE be ready for wide use.

MitM https

[Anonymous Coward]

Searxes is flagging MitM proxies.
It also warn you if you're browsing with Chrome.

SSL =!= secure

[Anonymous Coward]

Encrypted is not the same as "secure".

HTTPS breaks intermediate caches

[tepples]

Encrypting the material in transit doesn't make any less freely disseminated or the information less free.

It prevents caching. Say a school in sub-Saharan Africa has only a 128 kbps, harshly metered connection for all its computers to use. With cleartext HTTP, if all the students visit the same encyclopedia page, a Polipo caching proxy inside the school can retrieve it once and serve it to 25 students in a classroom. But with HTTPS, the proxy can only handle the CONNECT verb to tunnel the connection to the origin server, causing transfer of 25 times as much data compared to the case with an intermediate cache.

Just be aware of the trade-off (bank hack yesterda

[raymorris]

Your concern may have some merit.
Just be aware of the trade-off. Remember the $100 million hack yesterday, where the same company got hit twice in eight months, from phishing attacks? Corp sec could have prevented those if they had visibility into what pages the employees were loading. They could have seen the employees entering their ldap credentials into corporateHR.ru and prevented it. Our SOC catches a LOT of that stuff.

Also catches and blocks a lot of malware, crypto-locker style ransomware, etc.

So you have to decide which is worse - crypto-locker and the bad guys having your ldap credentials, or your fear of the NSA seeing you reading Wikipedia. I don't think either answer is always right.

Diffie Helman

[Anonymous Coward]

WIth the diffy hellman key exchange *they* could build a secure connection right into the 2 big webservers and the 3 big browsers.

It could all be transparent.

Me,as both user and webmaster do not need to install nothing. double negative!!

Diffie Helman!! Exchange those frikcin. keys!!

Where it all goes wrong is the
1) The Certificate Mafia wants outrageous fees
2) Wanted some central authority to 'ceritfy' a website (which is the camel in the tent for central licensing of all websites)

The end-to-end secure connection is conflated with a central "trusted" authority saying your site is legit.

Somebody put an end to google and mozilla and their freaking out about me browsing an 'unsecure' site full of google tracking code, and facebook tracking code.

The https weenies need a good slap upside the head. Stop this silliness.

The amounts sites that have a 'bad' certificate is already breaking the web.

Re:Diffie Helman

[Opportunist]

You are aware that certificates have very little to do with encryption and are mostly about proving that you're actually talking with who you want to talk to, yes?

Great. Could we get educated users next?

[Opportunist]

Because we're now teaching the mantra of "encryption makes you secure", and people will swallow it. Unfortunately, it's not true. It is absolutely possible that you connect to hxtps://onlinebanking.bankofmurrica.com, log in and be surprised that suddenly your money is gone. Because encryption only means that traffic is secure between you and the target, and a certificate only says that the other side is who they claim to be.

What a certificate cannot ensure is that you're really connected to who you think you're connected to. So the next step, or even the step before, should be to teach people to read the fucking URL they communicate with instead of just going "oh browser says 'secure' so it's all right, let me just enter all my passwords".

But where's the money for Google in that?

Re:Great. Could we get educated users next?

[Anonymous Coward]

Brilliant example. FIDO U2F creates a token that is tied to the URL, so if you log in to onlinebanking.bankofmurrica.com, their server can't forward the token to the login page of the real bankofamerica.

But where's the money for Google in that?

Google Launches Its Own Physical Security Key

A not so subtle push to end independent hosting...

[groktrev]

Let's Encrypt is easy but not too easy. It benefits Google, Amazon, and others to make it harder for individuals to host their own services. Do all use cases require encryption? No, they do not.

Re: Just be aware of the trade-off (bank hack yest

[Anonymous Coward]

But soc doesn't need to intercept ssl; they have root on all the devices they care about and can monitor traffic there. Nothing stops attackers from shipping their own libssl and certificates but that won't stop a local debugger.

firefox and another search engine

[Anonymous Coward]

EOM

Re: And I think they also see the URL when you se

[Anonymous Coward]

This is sort of pedantic though.

They can still see you are requesting bigblackcocksxxx.com who cares if they can't see the /3-big-cocks-vs-midget they still already have the genesis of what you are doing.

https gives a lot of average internet users a huge false sense of security.

The browser does TLS internally

[raymorris]

The broswser does TLS, so system access doesn't give you access to monitor it. Not using safe APIs. An attacker with root could dig into your RAM or whatever, but that's not a safe approach.

Does average users even care?

[Anonymous Coward]

I canâ(TM)t remember too many who even care about this. Most users seem to ignore this security even when provided a visual reminder. I have agree that much of this seems over kill for some sites. Looks more like a money crap to have to buy a cirtificate for their site just to be approved by a web browser.

Re:The problem:ALL HTTPS is insecure and allows Mi

[Wrath0fb0b]

If you want at least some trust, you either have to BE the CA (like with my own servers), or meet and get to know the person *personally*. Everything else is just hearsay, and of comparable trustworthiness to whatever you receive when you send out an unencrypted HTTP request to a random unknown domain.

How do you go to the grocery store? Surely you don't believe that unless you personally milked the cow, you can't know that it's milk and of comparable trustworthiness to any white liquid you find in a random container, right? When people say that milk is inspected by the (fallible) FDA/USDA, do you scoff at their "argument from authority"? I mean, at some point in your life you must have had to accept that there are imperfect systems that nevertheless work reasonably well and that have means for self-correcting errors when they do happen. The vast majority of milk sold in the US is milk, and it's reasonable to trust the milk from a reputable grocery store even if you don't personally know who milked it.

I mean, there's plenty of legitimate criticism and improvements to be made about the state of CAs. It ain't perfect, but trust-nihilism isn't even close to a reasonable alternative.

A nudge is unwanted touching

[Anonymous Coward]

A nudge is still contact.
A nudge is coercion.
Unwanted touching is assault.
A nudge is still physical. Violence.

Re:The problem:ALL HTTPS is insecure and allows Mi

[Gavagai80]

Say you consider the CA nor the self-signed website owner equally trustworthy/untrustworthy. You're still much better off trusting a dozen CAs than a thousand website owners. Browser-trusted CAs allow you to risk your trust on as few entities as possible. You'll still get burned sometimes, but at least you'll be more likely to know who to blame.

Re: The problem:ALL HTTPS is insecure and allows M

[Anonymous Coward]

With groceries etc you can sue and win. Part of the point of hacking is to make it damned near impossible to get a legal remedy

Nudging

[Anonymous Coward]

Taking over things, one nudge at a time.

Re:The problem:ALL HTTPS is insecure and allows Mi

[thegarbz]

I think you're providing a nice counter example there. Symantec's actions as untrustworthy resulted in them directly losing their business. Same with some of the other vendors we had.

Ultimately exposure to users was limited, certificate revocations were issued, and the guilty parties punished. This is very much a system working as intended in order to maintain trust.

That's not to say you should blindly trust them, but given they actually have something to lose and standards which they need to uphold along with an auditable chain of trust, they get a hell of a lot more trust than random parties.

Re:The problem:ALL HTTPS is insecure and allows Mi

[thegarbz]

The entire concept of certificate "authorities" is already fundamentally broken by design. (Kinda obvious, given the "argument from authority" fallacy.)

I can not trust an organization that happens to host a website, but I'm supposed to trust an organization that happens to be a CA? Because the browser maker said so? Whose trustworthiness is not established either, by the way.

Yes and here's why: Browser makers don't work in a vacuum. Differences in certificate trust are easily checked on installed instances so you can see if one browser is acting nefariously vs the others. Along with that there are many very open browsers out there who very publicly discuss CAs (see Mozilla).

By extension those various browsers have power over the CA and they have demonstrated repeatedly to execute that power in order to hold the CAs to a reasonable standard. See Symantec, WoSign, or even state run CAs like CNNIC as examples of this system working in practice.

The result is trust through fear of retaliation, or rather as it typically goes, trust through fear of your entire business being given the death sentence. CAs have a lot to lose by breaching the trust of users and their actions in doing so are very easily traced thanks to the very public nature of their work.

You may not trust any random organisation, but you certainly have plenty of reasons to place more trust in a CA to ensure your channel is encrypted and the target organisation is who they say they are. ... Assuming you're not on a corporate computer that is.

Re:The problem:ALL HTTPS is insecure and allows Mi

[Anonymous Coward]

>I can not trust an organization that happens to host a website, but I'm supposed to trust an organization that happens to be a CA?

I think everyone agrees on CAs being broken, but the problem with HTTP is that we can't trust the *network*. We obviously trust the website's host (you don't buy things on Amazon if you don't trust Amazon), but we can't trust that what we're served actually comes from that host.

Re:The problem:ALL HTTPS is insecure and allows Mi

[Anonymous Coward]

By the way, I wonder how people can still trust their antivirus products after they proved themselves generally incompetent at security.

Re:The problem:ALL HTTPS is insecure and allows Mi

[Anonymous Coward]

They don't trust them, they just fear viruses and ransomware more, and it seems to me that they're not wrong.

Google is just a public floater dump now

[Anonymous Coward]

They have an agenda. They no longer want to fix things, just duct tape them over. with progressively encumbering duct tape..

Re:The problem:ALL HTTPS is insecure and allows Mi

[Anonymous Coward]

If you want at least some trust, you either have to BE the CA (like with my own servers), or meet and get to know the person *personally*. Everything else is just hearsay, and of comparable trustworthiness to whatever you receive when you send out an unencrypted HTTP request to a random unknown domain.

Someone on /. who knows what they're talking about. It still happens!
The blockchain has a great use case here. It should be trusted from a source that cannot be censored, not some backwater centralized SSL outfit.

how to code in https?

[Anonymous Coward]

I don't code in https, and the article doesn't explain how one codes in https.

Re:You shouldn’t have given Chrome market sh

[Anonymous Coward]

It's not even about the prices. They will simply deny you a certificate if you are doing something they, or the powers that be, don't like.

Excessive corporatization of Internet

[iamacat]

The whole point of HTTP and HTML is that absolutely anyone can implement and run a server or a browser. Otherwise we could have gone with webpages a interlinked Word documents served by Exchange servers. This brings us much closer to sucky closed design. I can't implement https server as a shell script and maintaining keys requires time and money. And simply hosting a webpage requires coding on client and server rather than just dropping a text file somewhere. We can't control what corporations and sheeple who are their customers do, but it's time to resurrect open alternatives. Just like WWW itself was an alternative to Compuserve and AOL. With any luck, we can also bring back intelligent independent content as an alternative to Fox News and CNN.

Annoying for a while now.

[houghi]

I have some local machines that have NO connection to the rest of the world. They are HTTPS, but having am official cerificate is not really possible as far asI know, because they can not be verified like my others do that you canb reach from the outside.

It is a sfucking 192.168.x.y address. Stop saying it isn't safe, ya dolt.

Re: The problem:ALL HTTPS is insecure and allows M

[Wrath0fb0b]

If a CA inappropriately signs a leaf cert, they will be booted from the big browsers.

This is not conjectural, multiple CAs have been ejected.

Chrome, the hero no-one wanted.

[Anonymous Coward]

Is it really Google's job to bully site-owners into taking action?

Who will pay?

[martinfb]

How about if Google then forks over the ever increasing cost of certificates/SSL for sites?

Many websites are hosted where only the host can install certificates. This significantly increases costs.

And then, HTTPS breaks and a new need for security arises!
Isn't unregulated life in a capitalistic world grand?!

Perhaps the take-away here is to buy SSL certificate company stocks before this faux bubble breaks!

Re: The problem:ALL HTTPS is insecure and allows M

[Anonymous Coward]

This should be the next slashdot poll. My answers are 1: I drive; 2: yes; 3: YES!;

This is just stupid

[proibido]

Forcing a website that serves only public content and requires no user input it's absurd!
Why spend the resources of encryption (well put by @RichardStallin) in something that needs none as it's already public information.
The only point I see in Google doing this is that they're concerned about sharing the user navigation history with others since forcing https doesn't affect Google Analytics but may affect other services who get their stats based on packet inspection.