Slashdot Mirror
Google Will Soon Let You Know By Default When Websites Are Unencrypted (softpedia.com)
An anonymous reader writes: Permanent changes are planned for future Google Chrome releases, which will add a big shiny red cross in the URL bar if the website you're accessing is not using HTTPS. Google says it is planning to add this to Chrome by the end of 2016, after one of its developers proposed the idea back in December 2014. Many have argued that the web is predominantly unencrypted, so they're displaying a persistent and ambiguous error message for a large portion of the Internet. Since unencrypted content is not an error state, the Chrome team should use alternate iconography, because the default error message this will just confuse average people, and it will encourage error blindness.
HTTPs only encrypts the contents of what you are retrieving, not the location (URL) that you are retrieving it from. Seems rather pointless to push it everywhere. It only has a purpose when the user and/or server want to exchange secret payloads (e.g. credit card numbers).
I'd prefer my employer didn't know the contents of what I post to Slashdot. You can extend this to just about any forum where ideas are exchanged.
Socialism: a lie told by totalitarians and believed by fools.
I thing the OP wanted the title to be "Google Chrome" Maybe one of the mods can fix that by at least replacing Google with Chrome.
Using that logic: The web is predominantly for porn. So we should label exceptions as SFW (Safe For Work).
Have gnu, will travel.
Get back to work.
HTTPs only encrypts the contents of what you are retrieving, not the location (URL) that you are retrieving it from. Seems rather pointless to push it everywhere. It only has a purpose when the user and/or server want to exchange secret payloads (e.g. credit card numbers).
Umm... the full URL certainly IS encrypted.
https://stackoverflow.com/ques...
Good, finally some parity compared to the situation where a browser like FF would through huge error messages around self signed certificates but would absolutely not yell or scream about plain text sites.
You can't handle the truth.
In fact, the URL is encrypted. The only thing that is not encrypted is the hostname. You should probably use APK's host file engine if you don't want the DNS request info to leave your computer (or use DNSSEC), and even then you'd have to disable SNI.
But I kind of agree. HTTPS is a nice concept, but its no silver bullet. It only protects your data on the way to the cloud provider or whatever you are visiting. The cloud provider still gets the unencrypted files. But yeah, HTTPS is something the cloud industry really likes. It protects the data from everyone but them. So they control it, and its their version of greenwashing.
HTTPs only encrypts the contents of what you are retrieving
HTTPS also blinds "proxies" and antivirus software which may have their own opinions of what should and should not travel over plain old port 80. ISPs have done stunts like ad injection, antivirus software routinely blocks websockets, and on and on. HTTPS is a godsend around this bullshit.
It also prevents tampering. Without HTTPS, not only can anyone along the path observe what you download, but they can also replace your client request or the server's reply. You visit slashdot.org, instead of you receiving slashdot you get a flash exploit exploit tailored to your user-agent.
As other people have pointed out, it does encrypt the URL. You might have been thinking that it doesn't encrypt the DNS lookup. Separate problem, both need to be solved. Lack of complete security is no reason to avoid incremental improvements.
So we used to have a simple system, see http:/// on the URL bar, or see https:/// on the bar.
Then some idiot got the bright idea of hiding the start of the URL, so users could be ignorant or infuriated.
Now they are going to use another symbol to indicate the lack of an "s"?
Have I really got this right?
(Hopefully in the future the symbol will be clarified by replacing it with a sequence of letters.)
I can't see any problem with showing clear icons for the state of the connection, which includes unencrypted being distinguishable from encrypted with a cert signed by an untrusted party (aka self-signed) vs a cert signed by a trusted party.
It's better than the current state of things, where the web browser programmers out right mis-interpret what is going on and potentially lying to the user.
For example, if I run my own CA and sign all of my own certificates, and push my CA public key by hand to computers intended to access my server, verified by hash fingerprints - this is arguably MORE secure than a "secure" public CA signed certificate that I have no control over.
After all I know exactly who signs certs with my CA - me - and despite what the public CAs and web browser programmers claim, I in fact do trust myself.
CAs are known to have signed fraudulent certs, so they are not the ultimate high tier of trust.
Of course the self-signed situation described above is very different from random snakeoil.crt style self-signed certs where the only possible way to verify the servers identity is to check the thumbprint hash. And who has time for that?
Displaying the lowest tier of security icon for non-https sounds just as useful as it has been since SSL was invented.
(After all, a lock vs a lack of a lock works good enough for anyone that cares about encryption, but I could care less what the two icons actually are of)
At least Googles approach is better than Mozillas by an infinite amount! .html files locally in firefox :P
I'd rather use Chrome and at least have it bitch about the lack of SSL while still actually showing me the webpage.
Firefox will soon actively remove non-https support and display an "unknown protocol 'http'" error instead.
Hope you don't like browsing
https://blog.mozilla.org/secur...
If you really cared about that you would not post at all because all they have to do is fingerprint the text you produce at work and then they can compare it against even anonymous posts. Author identification is not at all new, it was developed to help prevent student plagiarism.
Better to say what you want and fight for the right to say it, than to futilely try and hide under a transparent digital rock.
Just like that, huh?
ha ha ha ha.... your employer doesn't know?
My employer has deployed MiM SSL certs to all equipment and we access the web via a proxy. But Chrome happily displays the Green Secure Icon!
ha ha ha -- "my employer isn't watching me." [snork] that's a good one.
This is correct.
Common browser UIs seem to imply that the URL is metadata that is separate from content, but you can make unencrypted HTTP requests using a telnet terminal emulation session to the IP address of the server using port 80. If you do it becomes abundantly clear that the request URL, headers, and body are sent over the same unencrypted network socket. The browser has to parse the URL to the point of extracting the host name (e.g. http:/// foobar.com/requestPath), but the IP address is all that it needs to create the socket; the URI is then transmitted in its entirety on that socket.
When you use HTTPS the browser notices the difference in protocol and makes an encrypted connection to port 443. All the business of certificate are taken care of under the covers, and what you end up is just another socket. Everything else remains the same, including the fact that the only thing that gets transmitted in the packet header is the destination IP address and port number. Everything else is transmitted inside the socket (including the actual hostname you requested).
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Now I have to pay someone else to have a web site that will visible to the public.
... I don't even use cookies. Now big-ass Google is coming in and I need to pay someone else to have an encryption certificate.
... after three days I was not able to implement SSL on my server (help!?!). I suspect that implementation of SSL is one of those "if you know it - it's simple. If you don't - good luck".
My website is primarily static information (actually, it is only static information). I don't exchange any data (other than standard log files)
If things were bad enough, the last one I tried to implement
I'm forced to agree with this Slashdot poster. The use of a red X in this context will confuse users about perfectly correct and properly working websites, particularly legacy sites that carry no practical risks and contain widely referenced information, but that cannot be upgraded to SSL in a practical manner. The most likely outcome will be users learning to ignore such warnings completely because they will be so widely present and widely viewed as "crying wolf." It is also likely that many sites will push back against Google on this by posting explicit messages on their pages explaining to users that Google is playing Mommy and that nothing is wrong with their sites. It is perfectly acceptable and reasonable for Google to encourage the use of SSL. However, the approach being discussed is not helpful and is likely to even be counterproductive. REFERENCE: "When Google Thinks They're Your Mommy" - http://lauren.vortex.com/archi...
DNSSEC doesn't provide any encryption. It's not for secrecy; it's for authenticating DNS information.
Forgive my ignorance but this is an honest question - am I missing something?
I run about 50 websites, some for myself and some for local non-profit organizations. They're all simple information/brochure websites with no real interaction or sensitive content. For the life of me I can't conceive of any reason to encrypt any of these websites, yet it's going to cost me a small fortune in certificates to keep them alive in the future.
Why would I need to encrypt a website that offers nothing more than, for example, a list of local historical sites to visit? Thanks for any insights.
They finally figured out nobody pays attention to anything unless you give it bright colors. It's amazing how little we have evolved (or perhaps devolved) since our early formative years. Of course when people see a big red "x" they tend to panic somewhat (as red often symbolizes danger). But because a site is not encrypted doesn't necessarily pose a danger. If there was sensitive data being sent unencrypted (or even a password field and unencrypted), okay, alert them. But to encourage ALL sites to encrypt regardless of purposes/data to avoid the big red "x" from google Chrome...seems a bit much. I'm enjoying the Vivaldi browser so I think I'll just keep using that. :D
"Imagination is more important than knowledge" - Einstein
So they are forcing identification of all website owners.
So my simple web server, serving up some basic info - like maybe my most recent cat photos.. Are you saying that I *must* use SSL to do this? And to make SSL work I have to pay to get a certificate (cuz I don't really trust the freebie options yet). All so that visitors to my site will *know* that they are looking at cat pictures securely? That doesn't really make too much sense, and seems to suggest a broad assumption about the main purpose of web sites. Not everything requires an encrypted channel. Won't someone think of the kitties? All this hype about safeguarding the Internet for the kids, and not enough to remember that kitties need love too.
Unless Google certifies that all of its links are to HTTPS sites, then it isn't an error condition, because the site is both up and providing the information that you searched for. In that case, it's a warning. And warnings should be clearly marked as such.
If I mean to go to a blog site that I know is insecure, but Google hates that it doesn't have HTTPS and turns it red and puts a line through it, then I might believe that the site is either offline, or perhaps dangerous.
If Google wants a nice shield icon or something to indicate that HTTPS is good to go, I'm down with that. That's informative, and it helps me understand what sites are, or are not secured in that manner.
If they start shaming sites that don't use it, then that is activist bullshit. And with Google's market share of search, that's a near monopoly who is making your site look like shit so most of your audience is going to see it.
SSL is not exactly hard to set up, but its not entirely trivial. Some people don't want to have to muck around with it, and they shouldn't have to if they don't actually provide a service that needs to be secure.
I'd prefer my employer didn't know the contents of what I post to Slashdot.
So you use https://whatever.public.forum.... And your employer monitors your packets and sees a large number of packets to that address at times X, Y, and Z, and then scans the public forum for any posting close to time X, Y, and Z. They might see five different names at each time, but the intersection of those three sets will most likely be ... you.
Now, that evidence might not stand up in a court of law to convict you of anything, but your employer isn't going to care about that level of proof. You want to keep your employer from knowing what you are posting, you're already using a VPN, so the https part is irrelevant.
You can extend this to just about any forum where ideas are exchanged.
Not every website is a forum where ideas are exchanged. Not every website deals in personal or private data of any kind. Some websites are as simple as 'xtide', which allows you to select a location and a time and get back predicted tides. Pretty useful stuff.
I run an xtide server. I had to hack the source to put in a robots.txt so that indexers stopped beating it to death asking for page after page of predictions. I don't have time, and nobody is going to pay me, to hack in SSL so it can become https. When FF stops allowing access to it, those users will just lose access to it.
Ah right, seems I was wrong.
Then do what on break-time?
Of course the web isn't the internet. There are many ways around it.
When you use HTTPS the browser notices the difference in protocol and makes an encrypted connection to port 443.
Which discloses the hostname in the clear in the Server Name Indication (SNI) field of the ClientHello packet. Otherwise, if the server hosts more than one website, how does it know which site's certificate to use?
HTTPS makes filtering or caching in a proxy harder: the proxy operator has to convince the user to install the proxy operator's root certificate. It doesn't make IP address-based filtering, hostname-based filtering (hello APK), browser-side filtering, or browser-side caching any harder at all.
Unless the feature is going to be added not only to Google Chrome but also to Google Search. The latter already uses HTTPS availability as a weak tiebreaker for ranking.
HTTPS is encryption and authentication. Without HTTPS, anyone between your computer and the web servers can manipulate every part of the request and the web page. Mobile networks for example are notorious for adding headers to HTTP requests and "optimizing" the pages you get back.
No.
HTTPS encrypts the data transfer, and provides for VERIFICATION that a third party CA believes the site is who it says it is. No authentication involved.
it actively tries to impress upon the user that the https connection with a self signed certificate is worse than a plain text http connection
A URL using the https: scheme and an unknown certificate authority gives a false sense of security, while a URL using the http: scheme gives a true sense of insecurity. Browser publishers rank truth of sense greater than security.
What's an acceptable level of "verifiable accountability" to you? I assume HTTPS with a self-signed certificate. Is a domain-validated certificate enough? Or do you demand an organization-validated certificate because of the risk of someone registering bankofarnerica.com and obtaining a domain-validated cert?
Next, only content signed by "trusted" CA's?
Let's Encrypt is a trusted certificate authority. And I don't see that going away any time soon, as the division of Google responsible for Chrome is a platinum sponsor of Let's Encrypt.
My Chrome browser recently started putting up an error page because python.org's certificate was a few days out of date. The error page has a big blue button marked "back to safety", the other button is a little harder to spot. It was mildly annoying since I was using the online docs while writing a script and the browser forgets your "fuck off" answer to the error between sessions. I'm sure there's an option somewhere that will automate my willful blindness to this error page, I'm just too lazy to look it up
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
HTTPS is also used for (somewhat) authenticating the content. The problem is that any router in between you and eg Google can just remove/replace the ads (which is what they don't want) or even replace the ads with malware (which is what you don't want).
Using HTTPS by default just makes sense. There are plenty of instances where static pages on a cheap site suddenly become dynamic and later need actual user authentication and I've gone through a number of instances where SSL just started breaking shit in the ancient systems and cheaper people may decide to just cut their losses at that point.
Custom electronics and digital signage for your business: www.evcircuits.com
Now I have to pay someone else to have a web site that will visible to the public.
You already have to pay your domain registrar and hosting provider.
Now big-ass Google is coming in and I need to pay someone else to have an encryption certificate.
But you don't have to pay StartSSL, WoSign, or Let's Encrypt for a TLS certificate.
I run about 50 websites, some for myself and some for local non-profit organizations. They're all simple information/brochure websites with no real interaction or sensitive content.
The "sensitive content" is what a man in the middle could insert into your stream: pornography, libel, ransomware downloads, or what have you.
yet it's going to cost me a small fortune in certificates to keep them alive in the future.
Let's Encrypt certificates cost zip.
This is true. I have to confess I never looked up the details of the TLS handshake negotiation.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Files need a type (assuming out of bandwidth necessity, a stretch itself given many modern types encode what they are in the beginning of the data itself e.g. jpg) but that should be in another data field of the OS rather than repurposing part of the name.
How would a portable program specify the content type of its output? The standard library of ISO C provides no way to manipulate "another data field of the OS". Nor does the standard library of ISO C++. Which well-known multi-platform programming language's standard library does?
In the past ten years, I've seen exactly two sites that use a client certificate: Kount (e-commerce risk assessment) and StartSSL (a CA). It isn't very common.
Ah right, seems I was wrong.
Oh my God. Someone on /. (simply) admits he/she was wrong.
Thank you, dear poster. I can die now, to be whisked off to either a warn Heaven or very cold Hell.
It must have been something you assimilated. . . .
And even if you had money, you would have to renew certificate each year
Let's Encrypt automatically renews your certificate every couple months.
(for some reason these things expire)
They expire as a means of pruning the revocation list.
Other than that. I guess the other side of the argument to "why not use just use unencrypted HTTP?" is "if there is no cost involved and doesn't a lot of extra effort to set up, why NOT use encrypted HTTP?"
And the answer is that it does "a lot of extra effort to set up", at least according to Bomarc's comment.
If I only want to encrypt connection so it remained unmodified
A man in the middle can decrypt on one end and encrypt on the other end in order to modify the data. A self-signed certificate protects against only passive attacks, not active (man in the middle) attacks, unless you find some way to communicate the certificate's fingerprint out of band.
Easy solution. Allow self-signed certificates.
Then let me rephrase Anonymous Coward's post:
Use of a CA means your "list of local historical sites" remains exactly as you wrote it, and doesn't mysteriously lose mention of that awful thing which happened in 1846 that a local politician feels "school children just don't need to be taught" when it is viewed through a man-in-the-middle proxy on school WiFi. It also won't suddenly gain a banner advertisement for Amazon when viewed through the man-in-the-middle proxy of a certain US ISP. You presumably care about the "simple information" on your sites and want it presented as you wrote it, so that seems valuable, but without some means of detecting a man-in-the-middle proxy, there just isn't any guarantee at all.
HTTPS encrypts the data transfer, and provides for VERIFICATION that a third party CA believes the site is who it says it is. No authentication involved.
On the contrary, the HTTPS server is forced to authenticate itself as the holder of the private key signed by a CA. Verification is between the server and its CA, not between the client and the server, and serves as a preliminary to obtaining a CA's signature for the server's key.
TLS can also be used to authenticate the client using a client certificate or a password (TLS-SRP), but this is much less common.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Slashdot used to offer subscriptions. When it offered subscriptions, subscribers used HTTPS to view ad-free pages. HTTPS was treated as a subscriber perk because until September 2013, there were no major ad networks that worked over HTTPS.
So they are forcing identification of all website owners.
Whois already does that, thank you very much. And Let's Encrypt doesn't need any more information than what's already on your domain's Whois record before issuing a domain-validated certificate.
Firefox defines typing in s as indicating that the user desires protection from a man in the middle (MITM). Install the Perspectives extension, which adds a second method of detecting MITM that works with self-signed certificates, and self-signed certificate errors will go away.
Especially because SlashdotMedia just got bought out by BIZX, and some people think this is dangerous.
You can always come to SoylentNews. It has HTTPS, and we won't bite.
Not to mention that it is basically impossible to deploy any new feature or new protocol over port 80 (i.e. unencrypted) thanks to the 'help' of these proxies.
This is why you'll see that HTTP2 is deployed basically only over encrypted :443.
Amusingly, because of the 'helpful' proxies, HTTPS can be faster than HTTP. With the advent of QUIC (i.e. HTTP2 plus improvements), HTTP will almost always be slower unless the carrier is doing something (intentionally?) to screw things up.
On install or setup ask if they would prefer SSL only results/sites and inform them after the fact they elected for the option if they want to proceed to an unecrypted site. Kind of the same thing with sites that have certificate errors.
As others have said the warning thing will just add a layer of complexity that users ultimately won't understand.
how does it know which site's certificate to use?
Most secure sites should run on a dedicated server, not be shared with other domains websites on the same server, since it is a security issue.
But you could also use a unique IP address for each site hosted on the same server..... IP virtual hosting... present the right certificate when the right IP address is contacted.
This is also good, because not all browsers in use support SNI. For example, Internet Explorer on Windows XP does not.
Cacheable pages might have ads, but they're not The Right ads.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
. It doesn't make IP address-based filtering, hostname-based filtering (hello APK), browser-side filtering, or browser-side caching any harder at all.
Except IP address-based filtering is inherently hard; it's really not what you want to be doing.
Also, APK is garbage.... stick with OpenDNS or hostname filtering on your Firewall device, or on your DNS servers with BIND Response Policy Zones and some of the commercial real-time feeds regarding malware domains.
and provides for VERIFICATION
In security, there are exactly Three kinds of verification regarding a principal: Authentication - Confirms that a party is whom they claim to be
Authorization - Confirms that a party is permitted to proceed with the requested action
Auditability/Non-Repudiation - Confirms that the party commits to the requested action and cannot later pretend they didn't do it, or did it at a different time / under different conditions
No authentication involved.
INCORRECT. With the HTTPS protocol, a Server Certificate is used to Authenticate the server to the client.
In fact, the type of certificate required is one that has the serverAuth Key Usage (Short for "TLS Server Authentication")
You can see that over here: https://www.openssl.org/docs/m...
IE on XP doesn't support secure HTTPS, either.
Most secure sites should run on a dedicated server, not be shared with other domains websites on the same server, since it is a security issue.
Because of IPv4 address exhaustion, multiple dedicated servers would have to sit behind a load balancer with one IPv4 address that terminates the TLS connection.
But you could also use a unique IP address for each site hosted on the same server..... IP virtual hosting
This became impractical as of IPv4 address exhaustion.
Internet Explorer on Windows XP does not
...receive security updates anymore. It hasn't for 21 months. Therefore, it should be assumed subject to compromise by things such as keyloggers and therefore insecure.
An upgrade from my present cellular plan to one allowing tethering would cost roughly $50 per month, or $600 per year. At 2000 hours per year (full-time) and 25 percent income tax, this would reduce my effective hourly wage by 40 cents per hour. At 1000 hours per year (part-time) and 25 percent income tax, this would reduce my effective hourly wage by 80 cents per hour. But if an employer provides unrestricted break-time Internet, I don't have to pay $600 per year to a cellular company, and the employer can keep me as an employee without having to give me such a raise.
While it's true that https makes it harder to MITM the guy's blog or whatever, in my 15 years of full-time web security work, I haven't seen too many problems with MITM.
What I've seen a LOT more of, at least 200 times more, is hacked sites. Some Wordpress vulnerability or whatever and the bad guys ad malware to the public pages, while hosting phishing related pages in hidden directories.
A security- conscious company, head of household, or even ISP can largely protect users against malware that's been added to sites by detecting it at the firewall, as it enters the network. Unless of course it's https, in which case you can't detect the content at all. (Unless you do your own MITM, which often turns out badly).
So while https on a content site, a site that doesn't handle secure transactions, can theoretically reduce the risk of something that rarely happens anyway, it makes it much harder to protect against the far more common threat.
Overall, turning on the light and seeing what's flowing through your network is often safer than operating in the dark. In the dark you may -feel- like noone can see you, but in fact you can't see what's going on either. Often, what's hiding in the dark is more dangerous than being visible in the light.
That's just may experience, my fifteen years with the 70,000 or so client web sites I have data for.
The firewall can detect the hostname through the Server Name Indication field of the ClientHello packet, which is sent in the clear. If the hostname is known to have been infected, it can block the connection. It cannot detect the URL with path granularity, but if a site has been compromised, all paths on that site are probably shot as well.
So while https on a content site, a site that doesn't handle secure transactions
The Firesheep extension demonstrated that any site into which a user can enter a name and password, such as to post to the site's comment section or to read private messages or paywalled documents, is a site that "handle[s] secure transactions".
While it's true that https makes it harder to MITM the guy's blog or whatever, in my 15 years of full-time web security work, I haven't seen too many problems with MITM.
What I've seen a LOT more of is hacked sites. Some Wordpress vulnerability or whatever and the bad guys add malware to the public pages, while hosting phishing related pages in hidden directories. 99.9% of malware on sites is actually added to the site, not MITM by a rogue ISP or whatever. (And if you're buying internet service from a rogue ISP that alters web pages, you need a new ISP, not a red X).
A security-conscious company, head of household, or even ISP can largely protect users against malware that's been added to sites by detecting it at the firewall, as it enters the network. Unless of course it's https, in which case you can't detect the content at all. (Unless you do your own MITM, which often turns out badly).
So while https on a content site, a site that doesn't handle secure transactions, can theoretically reduce the risk of something that rarely happens anyway, it makes it much harder to protect against the FAR more common threat.
That's just my experience, my fifteen years with the 70,000 or so client web sites I have data for.
This is actually bad security. It is similar to the Vista UAC debacle. Vista taught a generation of users that they don't need to read security pop ups. By having them pop up way too often and without consequences if you don't read them for most of the time. Even if the user had read them, they wouldn't understand.
The user is the most important part of security, period. Thus teaching the user is more important than anything else, when you want to mitigate risk.
Google is making the web a lot unsafer with this.
Ha! I use Thunderbird, not Outlook. I don't even use Windows! I'm safe from AGW!
"So long and thanks for all the fish."
Well, some have. To scan for vira and malware. Many products can do this. Bluecoat for example.
the ip address isn't encrypted.
the url is.
lots of isps nowith mitm https by default. UK all the major ones do AFAIK. where it is impossible to establish a secure https connection using a secure CA.
A shade/brightness of red depending on scripts and input fields on the page.
rewriting history since 2109
Completely unnecessary. Many sites that only have plain-text, non-sensitive information will have a big "X" on them, scaring off unaware users. Google is forcing admins to get SSL certs for no reason
Most secure sites should run on a dedicated server [or] IP virtual hosting
If a site has its own dedicated IP address, then the act of accessing this IP address reveals the identity of the site that is being accessed.
Are you whiny, entitled people serious? Its work for fuck's sake. You have no right to free internet, or freedom of expression thereon, at work.