To give users who are not interested in this geeky stuff isn’t easy. But it’s clear that you must be careful with when you cry “wolf”. If you make a browser that says that sites like https://blog.wikimedia.org/ and https://www.libreoffice.org/ be “Not secure” or similar, no user will take your warnings seriously.
I don’t know how many sites that have a DV-certificate from Comodo, but I know that 47 million sites have a DV-certificate from Let’s Encrypt. For both CAs, a really tiny fraction of the issued certificates are used for phishing. Maybe about 0,6 ‰ (not %) for Let’s Encrypt, based upon Netcraft’s numbers (47 500 blocked sites, and 61 % of them using Let’s Encrypt).
One phishing site is of course one too many, but to flag DV as insecure because a tiny fraction of them are used by fraudsters makes no sense.
Indeed “how do you distinguish between good ones and bad ones?”. Good question. Not by looking at the certificate, but by looking at the content. To protect against fraud, good fraud protection is needed. Good spam filters, so users don’t get fraudulent links in their mailbox, good (fast) URL-blocking, in services like Safe Browsing and SmartScreen. Sadly, those are never good/fast enough.
BTW, I think most users of DV got the certificate through a hosting provider or CDN, by clicking a button in the control panel.
Finally, a CA issuing a Domain Validation (DV) certificates for a domain must only make sure that the applicant has control over the domain in question. It usually does so by sending (and receiving a response from) an email to the email contact in the domain’s whois details or an administrative contact in the domain (e.g. admin@). The CA may have no idea who the applicant for the DV certificate is – the whole process can be anonymous and untraceable.
Consequently, DV certificates offer encryption (i.e. assurance that the traffic to and from the website is encrypted, and therefore the sent sensitive data is known only to the user and the site’s owner), but do not offer proof that the owner of the site is a legal entity (existing organization), or a particular legal entity. In fact, with DV certificates the owner of the site may be completely unknown.
Sure, and I did not try to say they are not different. But I want the discussion to be nuanced. I will not call DV useless, and I will not call EV flawless. (What does it mean for users and their trust that COMODO CA Limited in Salford has been validated by COMODO CA Limited in Salford? “You can trust me because I trust me”?)
So there are scenarios when DV offers sufficient security? Like when I log in on forums using DV, paying attention to the URL?
And I guess most sites with DV are used passively, i.e. without the user entering any information (such as login credentials) on them. Maybe entering some text in a search box.
Is it flawed to click on a link on an insecure site (without TLS) to a site with DV? If that DV-site is unknown to me, it would not be wise of me to blindly trust it. But if the site instead has OV? If I bother to open the certificate viewer I will see a name and a location. Maybe I have never heard of the organisation, or even the city it’s located in. Should I blindly trust it?
I agree that DV should not be used for e-commerce or other financial transactions. I’m even disappointed that one of my banks has OV and not EV.
I think you guys are missing the point here. First, nobody is saying that DV certificates are completely useless. What is being explained here, is that DV certificates are neutral, period. Why?
For example, let’s say that you visit regularly the roughmedia.com website. You receive an email from roughrnedia.com where they ask you take advantage an activate a very good incredible offer. So you click, login with your personal details… but wait! Your account is no longer private. What happened, what went wrong? You submitted your private data over “a secure ciphered” channel! That’s right, you likely wouldn’t notice in the address bar of the browser that the owner of the website and the DV certicite has replaced the “m” in media with an “r” and an “n” that look very much like an “m.” That’s it for your private data, sent through “encrypted” enciphered channel.
Why would you need protection from eavesdropping and modification during transport, if the bad guy is the owner of the private key (yes, DV certificate).
We need to think broader and not only for ourselves but for those who have less experience in the web and are more vulnareble.
Assuming that the email was not caught by Gmail’s spam filter, and that Safe Browsing did not block the fraudulent site, and that I swallow the tasty bait, and that I am not surprised that Chrome suddenly does not remember my login credentials, and that I do not look at the URL-bar, yes, then I might give my login credentials to some bad guy. Is that DV’s fault? Does roughmedia.com also have DV, or maybe OV? Doesn’t matter, since I did not look in the URL-bar, not to mention the certificate viewer. If the user does not pay attention to anything outside the content area, different indicators for DV, OV and EV do not matter.
There are plenty of bad guys.
I have several times referred to average users, and how they might think and react in various cases. People with average or below average knowledge and interest in the matters we are discussing here are the big challenge for security engineers and UI-designers.
Different indicators for different certificates will not protect those users from fraud. Most people have no idea what a digital certificate is, and the indicator looks different if an image on the page is loaded over an insecure connection (Look at this forum!), so a changed indicator is not really a big thing for users.
I can sense a lot of trust in your Spam Filter, Safe Browsing, and your explorer for storing your credentials. Good! (Nothing to reply here, just pointing out positive things).
We are not blaming or poiting fingers at anyone, did I missed something? ???
Oh yes, it matters. Please select a group of people and create a familiar website for them with a self-signed certificate; ask them to input their usernames and passwords into your ‘familiar website’ where an indicator states that the owner of the website/certificate is not verified and might not be the person or company they are trying to submit their data to. Don’t worry, you can tell them that “their data is still going to be ciphered and be transmitted securely”… how many of them will want to do that? If you answer “none of them wanted to”, then indicators DO matter. If you answer “some of them did” or “all of them wanted to”, then congratulations! You just went phishing…
Yes, many of them using DVCs.
I wish I could read more about solutions and proposals to find solutions, rather than just “its not going to work”.
I know that they work (take a look in your own spam folder), but they are never good enough, never fast enough. Actually it is in Chrome I store credentials. I don’t have [Internet] Explorer.
Good. I got the impression that your fingers might be point at certain type of certificate.
Browsers don’t trust self-signed certificates. In Chrome I need to ignore the warning, click on Advanced and then click to continue the insecure site. That wouldn’t work for phishing.
If indicators matter, this phishing site (just an image of it) would not work, because it says “Secure” rather than “PayPal, Inc. [US]” between the padlock and the URL. Or maybe some indicators matter more than others.
And hugely much more good guys use DV, and would not use a certificate at all if they could not get one at no cost.
I can’t go and look at “my Gmail spam folder”. Sorry, I don’t use Gmail at all (never will). I lost my trust on Google many years ago (I don’t even use Chrome as web explorer). !ot!
No, read again… (you are missing the important thing). We never said that DVCs are bad. So don’t blame who is not blaming. What we said is that DVCs are not compliant with the definition of Encryption and hence their indicator must be neutral. Why? It has been explained over and over again in this thread.
Ahh, indicators. Good! So they do work. Thanks for replying.
Again, thanks for replying that indicators do work.
And that is exactly why DVCs indicator must be neutral because its not Encryption compliant. DVCs only codes (ciphers).
You are correcto amigo.
If DVCs’ indicator is neutrual, they would still be able to use DVCs for what they are intended to: Code/Cipher, not Encrypt.
I said “take a look in your own spam folder”. I did not say Gmail. Sorry for interpreting your explorer as IE rather than ‘web browser’.
I guess “we” means you and Melih? And the definition of encryption is the one used in Wikipedia. The word in the definition worth discussing is authorised. We are talking about communicating computers. The user’s computer connects to a server, and as soon as the connection has been established, both parties (computers) have been authorised to exchange information. Now, to make sure that no unauthorised party can access the information they exchange, encryption is used.
It is not the indicator that stops me from entering the site with a self-signed certificate. My browser simply stops at the doorstep, waiting for me to either go back to a safe site (recommended) or click to open Advanced, and click again to continue, despite the warning that it is insecure. That is very different from a passive indicator in the URL-bar.
Our different views on encryption aside, what does neutral mean? And how should HTTP without TLS look? Neutral, or insecure?
Cheers! So EV-indicators matter less than DV-indicators?
Whatever you call it, it is what it is, and does what it does. And it does the same if the site uses DV, OV or EV: it encrypts the data that two computers exchange.
We have different views or understandings of what authorised means. I have a technical view of authorisation, which I say must happen where the encryption and decryption happen, in the computers involved in the communication, not in anyone’s brain.
You say that authorisation is when you see a name in the server’s certificate. Right? When do you see the certificate? After your computer has connected to the server, and your computer’s software has decrypted the information (HTML and other stuff) it has received. Then you see that forums.comodo.com belongs to Comodo CA, validated by Comodo CA. Great. But wait, there are two parties in this communication. You see Comodo CA in the certificate, but what does Comodo CA see? An IP-address! Is that then – in your view – a fully authorised encrypted communication between two parties?
I see the encryption as a tunnel or tube, we can call it TLS-tunnel. The tunnel (if well designed and implemented) is perfectly sealed between the ends, but the ends are open. What are the ends? Not our brains, but our computers (any type of connected device). Those devices (the client’s device and the server) are where encryption begins and ends. My technical understanding of authorised is therefore that the two connected devices authorise one another, and any other device is technically unauthorised and unable to decrypt the data that is being transported between the ends. Maybe my view is flawed, but at he moment, I think it makes sense.
In anyone’s brain is the certainty to send one’s private data to the authorized party (roughmedia.com in our previous example) and not to an authorized party (i.e: roughrnedia.com). Period.
You well know where encoding starts (user).
If you want to submit your private data to unauthorized parties, even encoded so they can decode it, fine. I don’t want to do that and that’s why I think DVC’s should not be indicated as “secure”. Because an unauthorized third party can make himself look like an authorized party and take someone’s private data.
That client and server have authorised (allowed) one another to communicate (exchange data). It has nothing to do with the user, hence technically authorised. The user may have arrived at a site it would rather avoid, by clicking on an obfuscated link, or similar, but the site is none the less fully authorised to send data to the client. All the user can do is to unauthorise the server by closing the connection to it. A connection, secure or not, intended or not, means authorisation to communicate.