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.
And again, correcto amigo! DVCs does what it does, it only encodes and that’s it. Doesn’t provide a way to ensure data acces to authorized parties only. Hence, the need for a neutral indicator.
Connection is connection…just because its connected does not mean its “authorized”…
And again “unauthorized party” …you do NOT know if the person receiving the data is “different than” the “unauthorized party”.
All you are saying, whoever I connected to will receive data, but I don’t know if it is same or different than the “unauthorized party” that i am trying to avoid.
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.
Yes/No Question: If a connection is “encrypted” (according to your definition) fake Apple-like domain names are “authorized” to receive username and passwords from real Apple users/accounts?
No you did not. I was talking about the client (you) being unknown. So, to return to the example I used (you visiting forums.comodo.com), is it enough that one party (Comodo CA) is known to both parties, and that Comodo CA sees only an IP-adress?
It is technically authorised/allowed to receive whatever information. Encryption is not required for authorisation, and neither is authentication.
On top of the technical authorisation, we may add authorisation at the legal entity level, which of course requires authentication, preferably mutual authentication, where both parties are known.
Yes I did. You just have to answer the question: who is receiving private and sensitive data. Then you will find the answer who requieres authorization to receive that data.
Authorized by whom? Fake Apple-like domain names are authorized by whom to receive real Apple IDs?
Have you read nothing I have written? As soon as a connection has been established, the two connected parties are authorised to exchange information. The authorisation is in the connection.
The conversation appears to have moved to ciphers, encryption, authorization and how it’s done etc.
Haven’t we moved away from the question?
Quite simply, should DV certificates be given the same trust indication in a browser?
Given the level of validation required to get a DV certificate I personally would say no.
Oxford Dictionary defines “Encryption” as: The process of converting information or data into a code, especially to prevent unauthorized access.
And how does Oxford Dictionary defines “unauthorized”? Not having official permission or approval.
Regardless of a connection type, coded or not, if the person receiving the private data is “unauthorized” (not having official permission or official approval), the connection is not secure regardless it’s type (HTTP or HTTPS).
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.
