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.
That's great. Now, will Google let us know when it is tracking every thing we do online via its myriad of tracking technologies? Will it let us know when our email is going to be harvested for marketing data just because we sent an email to a non-google-appearing domain that was hosted on gmail? Will it let us know when and how it is logging our movements via android phones? Will it let us know what location data its "self driving cars" are going to be reporting back to google?
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.
You can also work instead of wasting away your work-time on private crap. I might surf some big sites from work, but I never go to privatly used forums or pages where I contribute. There are so many reasons why that should not be done!
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.
Bad news if your on an employers computer using their internet connection, they can still see everything.
We already suffer from error blindness;
"Since unencrypted content is not an error state" says who?
because to me it is. its not about the encryption, its about the verifiable accountability.
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.
I'd prefer my employer didn't know the contents of what I post to Slashdot
Your IT department can issue their own Certs and sniff on all your https traffic anyhow, or install keylogging/screen monitoring software. Or install cameras, or just stand behind you and watch over your shoulder.
Simple solution- stop posting from work.
Factually incorrect: The domain or IP is not encrypted, but the URLs and the content are.
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.
HTTPS makes filtering, caching and advertising content blocking harder.
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...
Seems to me that this great push towards https everywhere could lead to an unwelcome endgame. Tried viewing youtube through a proxy doing an m-i-t-m interception? Seems you can't with chrome and certificate pinning. Of course that's by design, and exactly what you want, but it means Google now has end-to-end control of the media. No slipping an ad-blocking proxy in there or otherwise tampering with or examining their content.
Now it's heading towards "no https, no play". Next, only content signed by "trusted" CA's? Nice way to raise the barrier to entry for the web.
Seems like the internet could end up as a proprietary, closed content-delivery system, just like cable TV was.
Anon, because tinfoil hat.
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.
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...
How about just showing the red bar if the HTML/javascript posts anything?
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
Not over an HTTPS connection. Unless they've implemented infrastructure and certificates for a MitM approach.
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.
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?
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.
You can have authentication, it's optional.
Both client and server are permitted to send certificates. As used popularly, only the server sends one, saying "Here, this proves I'm example.com".
But there are sites, and especially HTTP APIs that use the client cert for authentication, "Here, I'm bob@example.org" and the server verifies the certificate is from a CA it trusts, and if so whether bob@example.org is allowed to do whatever it is with the API.
The good news is that Google punishes sites that don't use SSL. (Even better when they do the honor by excluding crawlers via robots.txt.)
This helps nudge the web incrementally to a future of SSL everywhere. Can't wait.
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?
So, uh, when is slashdot.org going to run over https?
Didn't anybody notice?
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.
Can adblock+ do 16 things hosts do 4 speed, security & reliability:
1.) Protect vs. bad sites (past ads)
2.) Protect vs. fastflux botnets + stop C&C talk
3.) Protect vs. dynamic dns botnets + stop C&C talk
4.) Protect vs. DGA botnets + stop C&C talk
5.) Protect vs. downed DNS (4 reliability)
6.) Protect vs. DNS redirect poisoning
7.) Protect vs. trackers
8.) Protect vs. spam
9.) Protect vs. phish
10.) Protect vs. caps
11.) Get past dns blocks
12.) Keep off dns request logs
13.) Speed up surfing (adblock & hardcoded favs)
14.) Works on anything webbound multiplatform.
15.) EZ data control
16.) Block ads better vs. addons more efficiently
* ANSWER ="NO" on ab+ doing it as well or @ ALL + hosts = on devices natively.
APK
P.S.=> Ab+ does less vs. hosts less efficiently - hosts do MORE w/ less + Hosts start w/ IP stack before REDUNDANT inefficient addons BEGIN operation (as 1st resolver).
---
Ab+'s a 128-151mb memory hog http://cdn.ghacks.net/wp-conte... (hosts use 3-11mb w/ my program initially). Even FireFox 41 adblock eats 65++mb http://www.ghacks.net/2015/06/...
---
ClarityRay defeats it seeing addons via native browser methods!
---
Ab+'s bribed not to work by default http://www.businessinsider.com... & ABP bought out adblock http://www.theregister.co.uk/2...
---
Ab+ adds complexity in slower usermode (w/ more messagepassing overhead + context switch vs. hosts in kernelmode).
---
AdBlock's SLOWER: http://superuser.com/questions...
---
What's best?
APK Hosts File Engine 9.0++ SR-4 32/64-bit http://start64.com/index.php?o...
MalwareBytes' hpHosts Admin (MalwareBytes employee who verified its source is safe http://forum.hosts-file.net/vi... ) hosts & recommends it http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news...
&
It's safe per 57 antivirus programs in BOTH its 64-bit model https://www.virustotal.com/en/...
+
a 32-bit model too https://www.virustotal.com/en/...
& Installer -> http://f.virscan.org/APKHostsF...
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.
First, allow me to decide how MUCH of the URL to show in the address bar when I'm finished typing
ie: allow me to type cnn and hit return, knowing that it will resolve to http://www.cnn.com/ and allow me to decide whether I just want that displayed as www.cnn.com or as the full http://www.cnn.com/
Second, allow me to decide whether my browser should be even allowed to display non-https content. Because frankly, if you aren't using HTTPS on your site for EVERYTHING, you are doing your users a dis-service, period. I do currently use HTTP sites, but if this was the default behavior for all browsers, we would quickly see the entire internet switch over to HTTPS and I personally see this as a good thing.
Third, warn me and allow me to decide what level of SSL I want to support (I will always pick to ONLY support the most advanced currently unbroken SSL level). Again, if your site isn't using TLS 1.2 then I'm not going to be using your site.
Why is this so fucking difficult? I devised these rules in 5 minutes. Come on Google, get your Chrome team ahead of the curve.
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.
There are so many methods of silent remote machine administration with live screen view, that I dont even have to sniff a single packet to see what you're doing at your desk. Packets, proxy logs, firewall rules, etc. are just icing to the cake.
I would argue that in our new we are recording you world, unencrypted content IS an error state. Just like not wearing your seatbelt is an error state now. In the old days, it wasn't. And when those "BEEP BEEP WEAR YOUR BELT" signs came along, they were greeted with similar "useless warning" arguments. In fact, it was NOT a useless warning, and now everyone mostly wears their belts. Some day, all data will be encrypted, and it will seem just as dumb not to encrypt as it is not to wear a sealt belt in a car.
This hopefully will encourage more sites *cough*slashdot*cough* to enable HTTPS connections, and make them the default for all traffic. The more the internet is encrypted, the better. Keeps the spooks busy and hopefully in the dark (or at least wasting a lot of resources decrypting mundane traffic.)
That's not a solution, that's a chilling effect.
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.
You know, LiKe iT UsEd To Be!!!! (I werent allowed to use all caps for the desired effect since acording to /. its like yelling. I kNoW! ThAtS WhY I DiD iT!
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.
It's illegal in Europe for employers to monitor what you do on their network with their hardware? What kind of backward, anti-freedom hellhole do you live in?
Goodbye Slashdot, nice knowing ya!
Google Chrome will make Slashdot, and all other non-HTTPS websites, obsolete in 2016.
The warm Heaven seems more likely. Some findings have indicated that Heaven is Hotter than Hell.
(Then again, some of the conclusions are not necessarily universally accepted. Hell might be even hotter than Heaven's hot temperature. However, Heaven's heat wasn't a part that was in dispute.
These articles suggest that the possibilities are an eternal hot place and an eternal hot place. And you thought that global warming was making your outlook be scary hot...
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.
Yes! Yes, it is illegal in Europe! We have very strong protections for privacy and freedom of speech. Employees can employ technical measures, such as throttle or block sites like YouTube or Facebook, but they certainly can not monitor who accesses these sites, when and what they do on them. If there's reason to suspect criminal activity is happening, you know what? The police handles the investigation! And you know what else? When you go to the store and a smart-ass security guard stops and tells you to empty your pockets, you don't have to oblige! You can legally refuse such nonsense and ask for the police to do inspect you, after which you can file libel charges if nothing is found.
It's generally thought that employees have plenty of means to monitor the output of their workforce and that is how it actually is. Spying on their private messages is voyeurism at best, it's social porn for the superiors. It's a disgusting side-effect of the "job creator" cult people are taught to worship. A "job creator" is a citizen just like everyone else and have the same rights and duties.
People who think like you are the cancer of the United States of America (nothing personal against you per se). I wish you guys, especially the less-fortunate and poor majority, would wake up and realize that they *can* demand better standards. You *can* demand freedom and true individual rights.
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.
What's the point?
Once this feature gets implemented, by default any website will be considered insecure unless it uses proper HTTPS connection and the certificate is valid.
Then it would be just a matter of coherence to completely remove the warning when accessing an HTTPS website with an incorrect/untrusted certificate. I have never understood this warning and the extreme reaction from browsers in this use case.
A shade/brightness of red depending on scripts and input fields on the page.
rewriting history since 2109
"Principle: It is just important to be visually inconsistent when things act differently as it is to be visually consistent when things act the same
Make objects that act differently look different. For example, a trash can is an object into which a user may place trash and later pull it back out. If you want to skip the “and pull it back out” functionality, that’s fine. Just make it look like an incinerator or shredder or anything other than a trash can.
Make pages that have changed look changed. If someone encounters an unfamiliar page on an updated website or in a revised app, they know to look around and figure out what’s different. In the absence of such a cue, they will attempt to use the page exactly as they have always done, and it won’t work."
From http://asktog.com/atc/principles-of-interaction-design/
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
You can't tell what the URL was in a TLS/SSL connection, not without using MITM or being able to audit/malicious monitor the client/server side.
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.
I know it goes against all /. rules, but I went and read the original article. At the end there is an update saying,
"UPDATE: We were contacted by Peter Kasting, one of Google's engineers in the Chromium project, who told us we're idiots. But at least we're not the only ones. As Mr. Kasting's puts it: "In other words, there's no story here, unless the story is 'by the way, a year ago the Chrome team added a flag to do this and we just wanted to let you know that the flag still happens to exist'." So there's no permanent to Chrome coming by the end of 2016. We're sorry, but most of today's stories break via Twitter. Sometimes you get nice teasers, sometimes you get developers talking about their wishes and desires, instead of actual implementations."
So this is a non-story.
I'm hoping this get voted down sufficiently, so the tinfoil hat brigade and continue to lament about Google breaking the interwebs.