Google Will Soon Let You Know By Default When Websites Are Unencrypted (softpedia.com) 216
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.
title (Score:3, Insightful)
HTTPS sites rank slightly higher (Score:2)
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 [searchengineland.com].
Predominantly? (Score:2)
Using that logic: The web is predominantly for porn. So we should label exceptions as SFW (Safe For Work).
Re: (Score:2)
I thought the web was primarily spam and Netflix these days...
Wait... (Score:5, Interesting)
So we used to have a simple system, see http:/// [http] on the URL bar, or see https:/// [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.)
Re: (Score:3)
This shit irks me to no end. Windows is full of examples (hiding file extensions by default for instance)
Re: (Score:2)
To be honest, a file extension as synonym for type of file was an asinine hack from day 1.
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.
What do I #include to write that field? (Score:2)
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?
Re:Wait... (Score:5, Informative)
What we've learned is that not all HTTPS are created equal. There could be insecure ciphers, mixed content, insecure signatures, vulnerabilities, what have you. Just looking for the "s" isn't enough. It's a very good thing that the browsers, which can look at all the factors, are giving better hints about whether a connection is trustworthy.
Re:Wait... (Score:4, Insightful)
So we used to have a simple system, see http:/// [http] on the URL bar, or see https:/// [https] on the bar.
Are you on mad? They are both the same. Oh wait let me get my glasses. Oh they are slightly different. What the hell does the s mean? and that http thing? and why are there those two dots and the slashes? Is one supposed to be good and the other bad or something? If one is good and another is bad why not just replace them with a red x and a green tick?
Why does every software developer think that ever user is a damn guru hacker who knows that the big box under the screen is called the HDD? Wait what do you mean that's not right either? ffs I just want to surf the web, leave me alone with your complicated hacker stuff.
*An excerpt of a conversation many people have had with the very few computer users who understand the difference an s can make in the titlebar.
Re: (Score:2)
Re:Wait... (Score:5, Informative)
So we used to have a simple system, see http:/// [http] on the URL bar, or see https:/// [https] on the bar.
Only http:/// [http] is hidden, so users can still look for https:/// [https]. In fact, the difference is even more obvious than before: instead of just one missing letter, the entire protocol field indicates whether the connection is encrypted.
Re: (Score:3)
I know that, at least in FF, you can re-enable [mozilla.org] the /https?/ prefix in about:config.
Could still use improvement (Score:3)
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... [mozilla.org]
Re: (Score:2)
You apparently did not bother to read the blog to which you linked:
It should be noted that this plan still allows for usage of the “http” URI scheme in legacy content. With HSTS and the upgrade-insecure-requests CSP attribute, the “http” scheme can be automatically translated to “https” by the browser, and thus run securely.
Now isn't that special (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Plan "B"?
I've been trying to replace / upgrade the my key server; the upgrade is dependent on a change to the network. The change to the network involves finding need documentation on non-straightforward 'rout' commands.
Re: (Score:2)
I've not touched a Windows server since the days of 2k (and never ran SSL on it), so... I can't really provide much useful assistance I'm afraid.
Re: (Score:2)
The Let's Encrypt project will work just fine with Windows servers. You just need a compatible ACME client, and there are a few options available:
ACMESharp [github.com]
letsencrypt-win-simple [github.com]
Re: (Score:2)
Re: (Score:2)
You trust Microsoft to implement the features you need...
Now *THAT* is funny!
They (M$) keep pulling features I need, keep adding bugs (and features) I don't want. Further... key features that I do need as an administrator (Example: export / import a black list of IP addresses is not available.) I *WISH* I could move to a different OS (Linux) but that would add even more to my painful process.
Let's Encrypt (Score:2)
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.
Re: (Score:2)
You already have to pay your domain registrar and hosting provider.
I actually tried to avoid an itemized list. (Hosting provider: My basement)
But you don't have to pay StartSSL, WoSign, or Let's Encrypt for a TLS certificate.
As noted: After three days of working on just this problem; I was not able to implement SSL.
Re: (Score:2)
You already have to pay your domain registrar and hosting provider.
I actually tried to avoid an itemized list. (Hosting provider: My basement)
You already have to pay your domain registrar and your home ISP. Many home ISPs' acceptable use policies prohibit running a publicly accessible server from your basement, and they enforce it either through a firewall (blocking inbound connections on 80/443 or on all ports), through carrier-grade network address translation (CGNAT) which doesn't give your computer a public IPv4 address in the first place, or simply through threat of having your home disconnected from the Internet for twelve months. To avoid
Re: (Score:2)
You already have to pay your domain registrar and your home ISP.
I actually tried to avoid an itemized ... oh well
Many home ISPs' acceptable use policies prohibit running a publicly accessible server from your basement, and they enforce it either through a firewall (blocking inbound connections on 80/443 or on all ports), through carrier-grade network address translation (CGNAT) which doesn't give your computer a public IPv4 address in the first place, or simply through threat of having your home disconnected from the Internet for twelve months. To avoid this threat of disconnection, many customers upgrade to a business-class plan that includes an IPv4 address with inbound and no server ban in the AUP.
Google and non-SSL site warnings (Score:4, Informative)
Re: (Score:2)
There's no such thing as crying wolf in this case. The users just need to be taught if you see red, don't enter your credit card.
I see red sign and red x all the time, but they often have context as to what I can and can't do with them. This is no different.
Re: (Score:2)
Exactly right.
I swear, techies are so egotistical and think that nobody can possibly understand stuff.
Just spend some time training instead of immediately assuming that people will be confused.
More likely, techies are just lazy or afraid of dealing with people and would rather find the "solution" that involves the least amount of face time possible.
Re: (Score:2)
particularly legacy sites that carry no practical risks
There is no such thing. It doesn't matter whether the content of the connection is particularly sensitive; whenever you connect to any Internet site over an unauthenticated connection, an attacker can take advantage of that opportunity to substitute malware in place of the innocuous data you expected. Malicious scripts, injected third-party ads, exploit-riddled media filesâ"unprotected connections offer endless opportunities for those so inclined to take over your PC. The only way to protect yourself a
Why do I need SSL? (Score:2)
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.
Re: (Score:2)
I don't think anyone has ever said that.
All this is doing is upping the ante a little bit by expanding on the idea of the "lock" icon. As in, we have visual cues that tell us when a connection is secure, why not have some visual cues for letting us know a connection is not secure.
As far as I know, nobody is talking about refusing connections to non-secure sites.
Also, this is a Chome only thing. If you don't like it, use a different browser. Google is known to use their market dominance as a bully pulpit.
Re: (Score:2)
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?
If you don't use SSL then you're putting your users at risk, not because someone might find out that they're looking at cat pictures, but because someone can tamper with the unprotected connection and inject malware which appears to come from you.
And to make SSL work I have to pay to get a certificate (cuz I don't really trust the freebie options yet).
That's your problem. The free certificates work just fine, so there's no need to pay unless you run a big enough operation to warrant an EV certificate.
Just give the users the option. (Score:2)
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.
Cacheable pages don't load ads (Score:2)
Cacheable pages might have ads, but they're not The Right ads.
Re:Not Sure What the HTTPS Hooplah is all about (Score:5, Insightful)
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.
Re: Not Sure What the HTTPS Hooplah is all about (Score:4, Funny)
Get back to work.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
I'd prefer my employer didn't know the contents of what I post to Slashdot.
So you use https://whatever.public.forum.... [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
Re: (Score:2)
Break-time (Score:3)
Then do what on break-time?
Re: (Score:2)
tether?
Wage equivalent of not having to tether (Score:2)
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
Re: (Score:3)
Not all suggestions apply to all situations:
read a newspaper
Newspapers have moved to the Internet.
talk to your co-workers
Depends on whether they're on break at the same time.
get your employer to install a TV in the break room
It has become increasingly common to deliver TV over the Internet.
go for a walk
Practicality depends on weather.
Re: (Score:3, Informative)
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... [stackoverflow.com]
Re: (Score:2)
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:/// [http] foobar.com/requestPath), but the IP address is all that
Re: (Score:2)
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?
Re: (Score:2)
This is true. I have to confess I never looked up the details of the TLS handshake negotiation.
Re: (Score:2)
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.
Re: (Score:2)
IE on XP doesn't support secure HTTPS, either.
IPv4 address exhaustion (Score:2)
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.
Re: (Score:3)
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 industr
Re: (Score:3)
DNSSEC doesn't provide any encryption. It's not for secrecy; it's for authenticating DNS information.
Re: (Score:3)
Ah right, seems I was wrong.
Re:Not Sure What the HTTPS Hooplah is all about (Score:5, Funny)
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.
Re: Not Sure What the HTTPS Hooplah is all about (Score:2)
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 th
Re: (Score:2)
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.
Re: (Score:2)
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.
Automating error blindness. (Score:2)
Re: (Score:2)
My Chrome browser recently started putting up an error page because python.org's certificate was a few days out of date.
I wasn't aware that browsers use fuzzy logic for a certificate expiration date? I thought it was either expired or not-expired. They're not milk where's there's a little wiggle room past the expiration date, but more like condoms - broken or not-broken.
Re: (Score:2)
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.
Re: (Score:2)
. 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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 HTT
Re: (Score:2)
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.
Re: (Score:2)
Re:Good (Score:5, Insightful)
That's not my point, FF doesn't just warn people that the certificate is self signed, 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, because THAT is what a user compares his experiences to, not to another https site but to plain http.
My position on this is that FF goes to great length to make it seem that an https connection with a self signed certificate is less secure than http, while that is categorically untrue, it is at least AS secure as http. AFAIC CAs are not trustworthy themselves, https is broken, if you think your https session is really secure because it is signed by some 'authority', that's an interesting mental exercise.
Removing gigantic multi-screen warnings with insane messages about self signed certificates would help to increase overall security on the Internet by making it possible for people to use self signed certificates without making it look like self signed certs are a plague while not making the same types of accusations against plain http (which many sites also use!!! to transfer passwords).
Re: (Score:2)
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,
But it doesn't make that comparison. It tells you when a site is saying "trust me because I say I'm trustworthy". It says nothing about a site that says "I'm making no claims at all about trust." That's not saying that one is better than the other, just that one is something that the user needs to know about ("hey, this is https so it's secure, right?") and the other is the default.
My position on this is that FF goes to great length to make it seem that an https connection with a self signed certificate is less secure than http,
That's not what it says. That's your inference because you forget that http says nothing about security at all. How can you be
Re: (Score:2)
Of-course it does, it is trying to prevent people from using self signed certificates and pushing them towards CAs. FF today doesn't even display the protocol in the address bar by default, it shows either a grey globe or a green padlock, clicking on these you get 'connection secure' or 'connection is not secure' message. It's that easy to simply check if the certificate is self signed, treat the site as if it was an HTTP site by the browser and provide an appropriate status in the details ( self signed c
Re: (Score:2)
Of-course it does, it is trying to prevent people from using self signed certificates and pushing them towards CAs.
Is there a problem with that? StartSSL has been issuing DV certs without charge for years, and now there are also WoSign and Let's Encrypt.
FF today doesn't even display the protocol in the address bar by default
Firefox 44 shows the scheme for HTTPS and hides it for HTTP.
it shows either a grey globe or a green padlock, clicking on these you get 'connection secure' or 'connection is not secure' message. It's that easy to simply check if the certificate is self signed
Most users are unwilling to learn to check that pop-up every time.
treat the site as if it was an HTTP site by the browser
Because it's possible for http://example.com/ and https://example.com/ to return entirely unrelated documents, treating them the same in every respect is incorrect behavior. This means you have to define to what extent a browser ought to treat the
True sense of insecurity (Score:2)
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.
Re: (Score:2)
In the version of FF I am on right now 41.0.1 on Linux Mint 17 I don't see http or https in the address bar. I see a green padlock for https, you click on it and it gives you some details including saying 'secure connection'.
HTTP is just a grey url, click on it and see 'connection is not secure'.
Go to a site with a self signed certificate and get this crap:
This Connection is Untrusted
You have asked Firefox to connect securely to www.pcwebshop.co.uk, but we can't confirm that your connection is secure.
Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.
--get me out of here-- (button)
--Technical details-- (link)
--I understand the risks --(link)
Well, shit, I don't think most people actually understand the risks, but given that FF doesn't even show https in the URL any longer WTF is it doing tr
Re: (Score:2)
In the version of FF I am on right now 41.0.1 on Linux Mint 17 I don't see http or https in the address bar. I see a green padlock for https
I haven't seen this behavior. I've seen shown for HTTPS and hidden for HTTP. To help me confirm the behavior you are seeing, please visit some HTTPS site [pineight.com], take a screenshot, post it to Imgur or wherever, and link it here.
Get Perspectives (Score:2)
Firefox defines typing in s as indicating that the user desires protection from a man in the middle (MITM). Install the Perspectives extension [mozilla.org], which adds a second method of detecting MITM that works with self-signed certificates, and self-signed certificate errors will go away.
Re: (Score:2)
I am talking about every user that gets these errors
Every user that gets these errors can install the Perspectives extension to make self-signed certificates not dangerous.
and decides that the site is somehow dangerous in a way that the user doesn't understand, more dangerous than a http site, while in reality it is not more dangerous.
It's not about whether a site is dangerous per se as much as whether a site is as dangerous as a reasonable person would expect when keying in the URL.
and it will also put a big red 'birdy' near an http site.
I've already got a big blue 'birdy' on an HTTPS site [twitter.com].
Re: (Score:2)
It's not about whether a site is dangerous per se as much as whether a site is as dangerous as a reasonable person would expect when keying in the URL.
- that's complete nonsense. A person 'keying in' (most just click) a URL expects to get to the site. A browser actively trying to prevent a user from getting to that site based on the fact that the certificate for the site is not what the browser company decides is in the best interest of the company (AFAIC) is not an indicator of the site being secure or insecure.
In most cases nobody is hit with MITM attacks, however ALL communications are stolen and recorded by NSA and the like. It is better to be on
Re: (Score:2)
The major Free browsers show https: but hide http:. I tried them on a site with a domain-validated certificate from StartSSL:
Man in the middle (Score:2)
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.
Re: (Score:2)
If you do not encrypt, a third party can insert malware downloads into your site. Do "most websites just [not] need" a lack of malware?
Buck feta. Buck FIZX. (Score:2)
Especially because SlashdotMedia just got bought out by BIZX [soylentnews.org], and some people think this is dangerous.
You can always come to SoylentNews. It has HTTPS, and we won't bite.
Re: (Score:2)
Imagine a corporate network with an internet proxy server - everything you do, SSL or not, is readable by the proxy. If you accept the self signed certificate, you have no indication that securelogon.personalbank.com is really proxy.companyname.local siting in the middle. The self signed certificate might have been accepted on your behalf thanks to GPO.
The company's root certificate would have to have been deployed through GPO.
No consider that ISPs are very similar to a corporate proxy server regarding the man in the middle attack. They control the connection, they control DNS, they control everything.
But not the root certificate. (Yet.) This is the key difference between a home ISP and a corporate LAN: the former is less likely to try to install a proxy's root certificate on customer-provided equipment.
Re: (Score:2)
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 ico
Bank of Arnerica (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
Well, from what I understand Google's SPDY (which will become the next HTTP standard?) works over TLS and is significantly faster than HTTP 1.1
While I don't think that TLS is required for SPDY, I also don't think that it is going to be implemented without it.
So, basically, I think the next generation of HTTP protocol will (arbitrarily?) require TLS.
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 e
It does take extra effort (Score:2)
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 [slashdot.org].
Re: (Score:2)
...even though they can't give a sane explanation for why my call for a pizza to to ask my wife what we want to do for dinner should be handled with the same stringency as nuclear launch codes from the POTUS.
But, but...what if you asked for anchovies? Would you really want just anyone to know that? My god, man, think of your children. Or their children, or somebody's children.
You want MITM inserting porn in historical sites? (Score:3)
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.
Re: (Score:2)
I'm in the same position as you, with about ~100 sites of my own. The vast majority would not benefit in the slightest from encryption, yet it would impose significant costs and hassle on me to get certificates for every site, keep them updated, etc etc etc.
It seems pointless to me. No one gives a fuck if (for example) the recipe for Walnut Blueberry Muffins that someone grabs from one of my sites is "safe from prying eyes". FFS, I put it out there specifically so people could find it and use it. No one get
Let's Encrypt automatically renews (Score:2)
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.
MITM breaks self-signed HTTPS (Score:2)
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 a
Re: (Score:2)
Of course the web isn't the internet. There are many ways around it.
Google sponsors Let's Encrypt (Score:2)
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 [letsencrypt.org].
Re: (Score:2)
Google, Chrome and trusted really shouldn't be used together in the same paragraph.
Re: (Score:2)
I can remove the word "trusted" without loss of meaning.
Let's Encrypt is a certificate authority whose root certificate is included in the default root certificate set used by Google Chrome. 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.
Re: (Score:2)
because ad networks used to be SSL free (Score:2)
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.
Whois already identifies you (Score:2)
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.