No, a properly setup site cannot have it's HTTPS stripped, and even if it could it is the browsers job to warn the user that they site they are on is insecure regardless of why it is that way.
Problem is that browser warnings are sometimes false. Self signed certificates are not unsecure, the underlying encryption is still the same. The "unsecure" only applies to the CA, but that is not clear in the warning.
>Problem is that browser warnings are sometimes false. Self signed certificates are not unsafe, the underlying encryption is still the same.
Browser warnings aren't false, you're reading of them is false. Read around on badssl.com [0]. The self-signed warnings in chrome say:
>Attackers might be trying to steal your information from self-signed.badssl.com (for example, passwords, messages, or credit cards).
And when you click advanced chrome says:
>This server could not prove that it is self-signed.badssl.com; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
It says nothing about the encryption being bad, I don't know where you got that from. What it does say is that Chrome has no way to validate that the site you are going to is actually the site in the address bar. Encryption is pointless if anyone and everyone knows the password (oversimplified, but you get the point). Encryption without Authentication is as secure as normal HTTP.
Because of the term "unsecure".
Also Chrome says "This is not a secure connection". Emphasis on "connection". Which implies encryption (on that connection) being not secure. Which is wrong. What happens on the site itself is a layer above.
>Which implies encryption (on that connection) being not secure. Which is wrong.
No it is not wrong, even your confusingly worded sentence there is still fully correct.
Security (or encryption, or any other synonym you can come up with here) is made up of 3 (well technically 4) parts:
* confidentiality
* integrity
* authenticity
* (and technically non-repudiation, but that doesn't really apply here)
self-signed HTTPS certificates only provides 2 of the 3 (confidentiality and integrity) and it's that last one that is most important (authenticity), because without it you don't know who you are talking to. It could be your website, or it could be some asshole down the street pretending to be your website, you have literally no idea.
You say it's misleading, but it is you that is misreading and misunderstanding the concepts. Encryption without authentication is like encryption without a password. Utterly pointless.
The browser is implying that AES on that connection is unsecure. A better would be "might be unsecure". Because even if it's self signed, there is a possibility it's still the correct certificate.
Yes, because AES in that configuration IS INSECURE!
Just like my analogy, AES encryption with a password of nothing is "unsecure", and no matter how much you try to argue that it's still perfectly secure, you are wrong..
Just like this, the AES is pointless when ANYONE can set the password (or in more correct terms, when anyone can create one with the user in a DHKE). If you can't tell that the server you are talking to is actually the server you meant, then AES does fuckall, because the man-in-the-middle is the one that is setting the password!
You are doing the equivalent of telling me how secure your new house door lock is, while wiring it up to always unlock when someone rings the doorbell... All the security in the world won't help you when you give everyone a way to bypass it instantly.
Only if you verify that it is the same cert before you visit the page.
Luckily browsers will show you the warning saying that page is insecure, and give you the option of going there anyway after you have validated that the cert is the same.
