41–48 of 48 posts
The biggest practical issue that I have with the author's advice is that most people just want to type domain.tld into a web browser. This will guarantee that most people will get the http version of the website which is not ideal. You'll get a large number of, you should add security to your site messages. Also, Many firewalls (looking at you fortinet) block http by default and only allow https through. So in additi…
https://blog.chromium.org/2021/03/a-safer-default-for-naviga...
Earlier quoted context omitted.
1: You can always use a stronger encryption. You don't have to use decades-old encryption that has already been compromised. 2: So clearly in this case the route wasn't trusted. The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed. 3: Intranets are vulnerable only if there is untrusted devices in the network. As I wrote, enc…
> The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed. When designing anything that's going to be used by the general public on the Internet, you have to keep in mind that's the entire public, including grandma and grandpa that don't even realize that their Facebook app is not Google and post their search queries as status…
> Showing the user nonsensical warnings like "Someone is trying to steal your credit card information!!!!11" only creates confusion and misconceptions about security. So is this suggesting that browsers should automatically trust all certificates? The Kazakh government sure would like that to happen.
> There used to be a time when malicious websites usually didn't have encryption at all, or if they had, their certificate was self-signed. Let's Encrypt changed that. Now every malicious site has a certificate that appears trusted, and there will soon be a need of having different levels of "trust", where free-of-charge certificates like the ones from Let's Encrypt will become essentially untrusted. First off, this…
A self-signed certificate can also be used to make sure that the connection is private. Sometimes the private key may have leaked and then the certificate can be "trusted" without being private - though it's easier to just register a lookalike domain and a certificate for it than have a leaked private key.
Imagine Let's Encrypt disappeared tomorrow. Not an outage, but just up and vanished from the face of the earth. Maybe they get raided by the FBI. Maybe all of their engineers suddenly die. Whatever, it's gone. How much of the encrypted web would cease to function and when? We'd still have their certs in our browsers, but no one would be able to get a new cert. Many would revert back to unencrypted because they don't…
All browsers (even smartphones) support importing certificate files. The exception are Windows PCs on domain lockdown. Non-corporate-supported browsers might transition to being more friendly to this process instead of the unhelpful and scary SSL warnings provided now. Phone app traffic that isn't through a browser would be in a rougher situation, but it would be solveable by your major phone app store providers offe…
That's exactly what I would like to see happening. The current warnings make no sense and they only make security worse.
Browsers are not different from any other applications at this.
Earlier quoted context omitted.
I believe the flow allows you to view certificate information prior to accepting, and then only that certificate will be accepted for only that hostname.
Which browser do you think that's true for, and, have you tried it?
You just need to click on the "Not Secure" warning that's where the lock symbol would be, then on "Certificate is not valid".
Earlier quoted context omitted.
> The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed. When designing anything that's going to be used by the general public on the Internet, you have to keep in mind that's the entire public, including grandma and grandpa that don't even realize that their Facebook app is not Google and post their search queries as status…
I am living in reality. I don't want to limit the user's freedom. Sometimes people have to learn the hard way, but the other option (giving away your freedoms) is always worse.
This isn't reasonable or ethical - and it's telling you didn't respond to my other comment replying to you.
If someone experiences harm due to use of unencrypted HTTP because they didn't understand the implications of it, they're not going to be able to make a causal association. Without the causal association, there is no opportunity to learn.
The way to "preserve freedoms" in these sorts of situations is to require a "warranty voiding" action.