Slashdot Mirror
Half of all Phishing Sites Now Have the Padlock (krebsonsecurity.com)
You may have heard you should look for the padlock symbol at the top of a website before entering your password or credit card information into an online form. It's well-meaning advice, but new data shows it isn't enough to keep your sensitive information secure. From a report: Recent data from anti-phishing company PhishLabs shows that 49 percent of all phishing sites in the third quarter of 2018 bore the padlock security icon next to the phishing site domain name as displayed in a browser address bar. That's up from 25 percent just one year ago, and from 35 percent in the second quarter of 2018. This alarming shift is notable because a majority of Internet users have taken the age-old "look for the lock" advice to heart, and still associate the lock icon with legitimate sites. A PhishLabs survey conducted last year found more than 80% of respondents believed the green lock indicated a website was either legitimate and/or safe. In reality, the https:// part of the address (also called "Secure Sockets Layer" or SSL) merely signifies the data being transmitted back and forth between your browser and the site is encrypted and can't be read by third parties. The presence of the padlock does not mean the site is legitimate, nor is it any proof the site has been security-hardened against intrusion from hackers.
In reality, the https:// part of the address (also called "Secure Sockets Layer" or SSL) merely signifies the data being transmitted back and forth between your browser and the site is encrypted and can't be read by third parties. The presence of the padlock does not mean the site is legitimate, nor is it any proof the site has been security-hardened against intrusion from hackers.
Really? What's the thing underneath me that's approaching me really fast, here up in the sky? I think I'll call it ground. I wonder if it'll be friends with me. When writing or excerpting for Slashdot, please assume at least some minimal technical knowledge.
Also, of course people believe SSL is more than it is; companies have been pointing it out for years as proof they're secure.
And this is what we get for browsers forcing websites to adopt HTTPS or else they try to scare people with warnings about pages not being secure. I run a site that provides 100% publicly available information in a totally read-only / user agnostic manner. There are no accounts, no sessions, etc. Just the display of information. I had to switch to HTTPS because of uninformed users thinking something was wrong with my site because of browser warnings.
Now users have a misguided trust that since a browser didn't warn them about a site, and since it has a secure padlock, it must be safe. Sounds like the type of solutions politicians end up creating to fix one minor problem yet causing several more severe ones. It's not the job of web browsers to force websites to be secure. Just because they can wield such power because of the technical aspects doesn't mean they should.
Better known as 318230.
I understand X509 is complicated and most people do not want and do not need to understand how it works. However, all browsers went too far in dumbing down this aspect and we are now seeing consequences.
/. It takes me multiple clicks to determine that it currently uses certificate issued on October 23, 2018, for Slashdot.org, and it uses Letâ(TM)s Encrypt issued certificate (cheap bastards). Why is this information so hard to access?
For example, when navigating to
more than 80% of respondents believed the green lock indicated a website was either legitimate and/or safe
Really? Is that level of misunderstanding so pervasive?
How do we fix that? Can our schools start to teach things like this, instead of "how to use javascript 101" for people who'll never in their life need to write a line of javascript? Those same people WILL need to know how the internet works, so let's teach that instead.
I think we are expecting web browsers to be our net nanny these days. It has been my experience that the informed and educated user is the one who can use the web safely because they know how to do so. No feature or safety implementation in a browser can protect you when you can't recognize the obvious.
I give the "lock & URL" advice to people all the time - isn't that enough? You do need to be sure that its gmail.com and not gmale.com, part of being an adult netizen.
These Certificates are often expensive, relatively complex to setup rarely ever give any real value. A self Signed Cert will offer the same level of encryption (sometimes more, because the Cert Authorities may pay more for automatically generating more bits). The original value of these Cert Authorities was so we would be sure that the site we went to was an authentic business, where you could prove you are who you say you are. But they have been giving certs to anyone without any research just as long as you pay the bill you are good to go, so you are not getting value out of these Certs except for the artificial browser scary error that you are a horrible person for using a unauthorized Cert.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
There are indeed people who would think the way the article describes.
Hmm, maybe Chrome making the lock gray now wasn't as dumb as I thought. While the absence of https (at least according to Google) is baaaaad, the mere presence of it doesn't mean all that much.
I run a site that provides 100% publicly available information in a totally read-only / user agnostic manner. There are no accounts, no sessions, etc. Just the display of information. I had to switch to HTTPS because of uninformed users thinking something was wrong with my site because of browser warnings.
In the case of a static website, the primary reason for HTTPS is to ensure that your viewers' ISPs cannot falsify the "100% publicly available information" on its way from your server to the browser. Xfinity by Comcast has been caught inserting ads into HTML documents transmitted through cleartext HTTP on multiple occasions.
The purpose of HTTPS everywhere is to force everyone to register. This is Orwellian, not a good thing.
But centrally managed certificates are definitely not a help.
What should have been done was make SSC(Self Signed Cert)s give the yellow warning icon, improper authoritative certs give the red/broken lock symbol, sites with matching authoritative info getting the green lock, and then add a pinning option that pops up certificate information only for certified+pinned websites, allowing the user to have visual notice if it is a site they normally visit or a possible phishing site.
Honestly cert pinning needs to become the standard, because only the end user can authorize trust in the end. If they do badly, that is on them, if they do well, then it is also on them and helps avoid both criminal and state level hacking by ensuring they know the proper certificates for the websites they frequent and authorized them at some trustworthy time in the past.
If issuer is obviously not doing their job properly prior to issuing the certificate, then their certificates should not be trusted by the OS and the browser
I think it has something to do with a misconception of what "their job" means. Let's Encrypt, SSLS.com, and other CAs specializing in "domain validation" think the job of a TLS certificate authority is to ensure that only the entity that controls a hostname can act as that hostname. The "organization validation" camp, which includes the "Extended Validation" camp, thinks a certificate also ought to identify the real-world business behind a particular hostname. They use as an example bankofarnerica.com belonging to someone other than Bank of America Corporation.
This is why proxy re-encryption has become popular.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
No one ever told me to look at the padlock
No, but when you either get a padlock or "Not Secure" (Chrome), it still gives a misleading impression. Most people are not computer savvy and do not understand (or know) there is a difference between secure and safe.
Some of these CAs have been caught giving out certs to non-owners of websites and when those CAs are big enough they won't get removed from the list.
You mean like WoSign and Symantec, whose roots browser publishers have phased out?
And how should it? Who'd know what you WANT to connect to but you yourself? Maybe you do want to connect to https://www.comparethemeerkat.... and not https://www.comparethemarket.c...
(and yes, they both exist and the former is an advertising gimmick for the latter)
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The issuer is doing its job. The job of the issuer is to verify that the domain name is properly pointed at the right IP-Address. What else would you consider the issuer's job?
That you think www.mybank.com.cn is www.mybank.com is YOUR problem. Not the CA's.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The site REALLY IS the site it claims to be
I guess it depends on how you define "the site it claims to be". If you write "snadze" in Cyrillic,* it'll resemble "chase" except that the "h" will be a small capital. The Punycode form of this name part is xn--80akwp6h. If you then go register xn--80akwp6h.com , you then prove to a domain-validating certificate authority that you own xn--80akwp6h.com, which a browser will display as "{snadze}.com" except with the actual Cyrillic letters. At this point, you can fool people who don't check the URL bar very closely into thinking they're on JPMorgan Chase N.A.'s website when they're not.
Or even staying inside Latin script: "bankofarnerica" isn't Bank of America.
* The letter dze comes from Macedonian Cyrillic. I can't show the real name because anti-vandalism measures implemented on Slashdot after the "(5:erocS)" incident disabled Cyrillic.
HTTPS was never designed to verify if a website is trustworthy or validate that they will do good things with the data you send to them. The only thing is does is ensure that you can be sure you're talking to the actual website you asked for based on the URL and that nobody else read or changed the data sent by the server as it traversed over the network.
If we really want to protect things like user credit card numbers we should have a system where we don't have to send our credit card details to a website that we want to do business with. This would work similar to PayPal in which you can do a payment to a third party website without actually giving them your credit card number, except PayPal would be replaced by a Visa/MC/AMEX service.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
> In reality, the https:/// part of the address (also called "Secure Sockets Layer" or SSL)
SSL was a protocol used by Netscape in the 1990s.
For ten last decade or two we've been using TLS.
I don't have to look at the padlock, but when I do, I've often seen the word "Secure" right next to it, even when I know it is not the case. Browsers blindly plopped that word on any HTTPS page, giving a false user impression for anyone who randomly glances in that general direction.
The "https" system was basically announced as secure since ~1995, originally via popups. This implied that it's secure in that you aren't going to get phished, have content tampered, etc. While the notification changed from a big popup over to an icon in the status bar, I still consider it a big issue when it's misrepresented as secure.
Still won't help, one just needs the domains that uses unicode characters that look like English letters, or simply have a typo similar to switching "l" and "I" around. This requires going back and forth between the browser and some external program to check the text, and eventually causes the user to become bored of this excessive verification.
Or worse, a punycode domain that looked like apple.com - something that was a problem with Google Chrome previously.
So there's a 49% chance that /. is a phishing site. Yikes!
All these problems could have been avoided if Let's Encrypt had know about RFC 3514.
#DeleteFacebook
Governments issue corporation documents and reasonably track that information. I remember needing a state ID along with paperwork to incorporate.
The government can relatively CHEAPLY use open source tools and some existing servers to digitally sign things.... SSL should be using MULTIPLE signing parties with the government incorporation data and it's "stamp of approval" for the corporation behind the site existing. At least then you can trace it back to the government and then to the business owners.
3rd parties signing off on network security, storage security, malware security, privacy or BBB or whatever they do to approve. These should involve classes of approval: a simple string indicating the class of approval, start with a standard list that the browsers can react appropriately to. Such as warning users if a credit card is entered into a site that lacks a certification for that purpose; address info, etc.
Democracy Now! - uncensored, anti-establishment news
[Early notices about navigating to an HTTPS site] implied that it's secure in that you aren't going to get phished, have content tampered, etc.
I seem to remember the notices being phrased to the effect "Information you submit cannot be seen or changed by others while in transit". That covers the case of tampering and MITM phishing but not typosquat phishing.
Oh, and to do the work they also have to receive an encrypted email too, so they basically have to have a key exchange with the instructor, unless they know someone who has already done that and instead, use a trusted introducer.
In the case of face-to-face instruction, a key signing party at freshman orientation is practical. But in the case of an online university, how would trusted introduction be accomplished?
So, it really would be a good test for whether or not someone is ready to graduate middle school.
Now you mention that you meant middle school, not college. In the case of middle school, how would a student with underprivileged parents afford a computer and Internet access in the first place with which to complete and submit homework? I don't see how it would be practical to expect every student to work to afford his or her own computer, as the child labor laws of the several U.S. states tend to prohibit any sort of non-farm employment until age 14, and most entry-level employers include in the job description at least one duty that states prohibit until 16.
Unfortunately it's been peddled in "computer magazines" where writers who, at the most, know that TCP ain't the abbreviation for the Chinese secret service hand out advice to their even less computer literate audience.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Let's Encrypt does exactly what the certificate issued can do: Verify that the webpage the traffic originates at is the webpage in the URL line. Nothing more, nothing less.
And no CA can actually guarantee anything else.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Try using a modern certificate in an SSL server, such as Apache 1.2.
Some people mistakenly call it SSL. That doesn't make it SSL.
For example, you can call OpenVPN an SSL connection, but the fact is, it doesn't support SSL and it never has. It speaks TLS.
Actually they are the problem. The majority, and yes I mean that, of these phishing sites are using letâ(TM)s encrypt certs.