61–70 of 118 posts
YOU ARE DESTROYING THE INTERNET Training users, who have no way to properly asses this risk, to click OK to the SSL error, is like Jim Jones's practice runs drinking the Koolaide. Firefox had it right when the briefly made it impossible to OK the use of misconfigured SSL. Most IT people don't understand the risk of self-signed certs. We can't expect users to make good choices here.
YOU ARE DESTROYING THE INTERNET Training users, who have no way to properly asses this risk, to click OK to the SSL error, is like Jim Jones's practice runs drinking the Koolaide. Firefox had it right when the briefly made it impossible to OK the use of misconfigured SSL. Most IT people don't understand the risk of self-signed certs. We can't expect users to make good choices here.
Of course, very few clients support DANE as of yet. Nevertheless, that is the most modern solution and you'll spur adoption of DNSSEC and DANE if you offer it to clients.
Earlier quoted context omitted.
http://www.scmagazine.com/researchers-detect-ssl-mitm-attack... About 0.2% for Facebook is MITM. And they are not using self signed certificates.
I'm going to go out on a limb here and say that the vast majority of that 0.2% are people sitting behind corporate proxies with a fake CA cert installed and pushed out to workstations via Group Policy. A hostile (and targeted) MITM could remove or alter the JavaScript that posts the fingerprint back to the server in which case it would be very difficult to detect. The problem with Self Signed Certs in a practical sen…
This phrasing is misleading. Self-signed certs will protect against passive attackers, assuming the certificate can be verified out-of-band[0].
If the validity of a self-signed certificate cannot be verified, yes, it could be issued by a MITM. But it still protects against passive attackers, and the NSA (so far) has predominantly been considered to be a passive attacker.
Self-signed certificates are arguably more secure against LEO/NSA, because (again, assuming the validity of the cert can be verified), it is harder to MITM clients without the server admin finding out. With a CA, they can serve a subpoena to a third party (the CA) and force them to present a compromised certificate as "valid". For the LEO/NSA to masquerade as the legitimate server, it would have to subpoena the server administrator.
[0] Which is always required with SSL. CA-issued certificates are also verified out-of-band, just indirectly (via the chain of trust).
https://www.startssl.com/ gives out free SSL certificates. Just don't expect much on their part, given it's free. For example, they refused to reissue certificates for free after Heartbleed. Also you can't use them on commercial sites. otherwise https://www.gogetssl.com/ is probably as cheap as it gets.
If you read startssl'a justification on the free cert, you'll see that they charge in relation to the time they need to spend. A low level 1 year cert involves no human time. They don't have fully automated systems for revokes/reissues, so it's pretty lame for people to complain about them charging for it.
From a security perspective, however, I think you need to meet some minimum standards to remain credible as a CA, and I think at least being willing to revoke certificates that may have been compromised for free and very quickly is one of those standards.
I find it difficult to support retaining StartSSL certificates as trusted-by-default in browsers given their response to Heartbleed and the consequent relatively high probability that any certificate ultimately depending on them has been compromised.
Earlier quoted context omitted.
A site claiming to offer cryptographic security when it is in fact not is, in reality, worse than a site that simply doesn't offer cryptographic security. Both those sites --- the SSL site and the non-SSL site --- aren't offering security. But only one of them is also being deceptive about it. However, you'll get no argument from me if you constrain your argument about dismal mis-design to browser UI/UX. The browser…
Unauthenticated SSL does provide security against passive attackers , which is what mass surveillance in developed countries is. If the NSA ever insists on widespread MITM of connections, we have much bigger problems. I agree the UI needs to be properly worked out so that eg a bank can't be downgraded to an unauthenticated certificate.
CA-signed: Green lockpad
Self-signed: Yellow lockpad, with question mark superimposed over it
Regular HTTP: Orange, no lockpad (insecure)
Invalid or revoked cert: Red, "stay away" displayed within tags.
The current UI that most browsers present implies that self-signed certificates are worse ("scarier") than regular HTTP, which is not true.
If your zones are signed with DNSSEC, just add a TLSA record for the self-signed certificates to the zones. Clients with DANE [1] support will then recognize that the self-signed certificates are valid. Of course, very few clients support DANE as of yet. Nevertheless, that is the most modern solution and you'll spur adoption of DNSSEC and DANE if you offer it to clients. [1] https://tools.ietf.org/html/rfc6698
"It is strongly recommended that you do not enable this option unless you have a good understanding of what it is and does: you could easily make your domain name inoperative."
which doesn't exactly inspire confidence, especially since most small website owners (such as myself) really don't have a good understanding of it!
One thing that always confuses me is the plethora of options for buying SSL certificates. I understand the difference between a single domain and wildcard SSL. But, as an example, what's the difference between Positive SSL and Essential SSL (2 types of SSL certs sold by Namecheap) - Essential being about 3x the price.
If your zones are signed with DNSSEC, just add a TLSA record for the self-signed certificates to the zones. Clients with DANE [1] support will then recognize that the self-signed certificates are valid. Of course, very few clients support DANE as of yet. Nevertheless, that is the most modern solution and you'll spur adoption of DNSSEC and DANE if you offer it to clients. [1] https://tools.ietf.org/html/rfc6698
Off-topic, but speaking of spurring adoption of DNSSEC: does anyone know of any good (dumbed-down) guides on setting up DNSSEC on personal domains / using dnssec-keygen? I keep seeing it mentioned in HN threads as a Good Thing, and I know my registrar supports it, but they have a big warning: "It is strongly recommended that you do not enable this option unless you have a good understanding of what it is and does: yo…
Opinions on DNSSEC are... mixed, to say the least: https://news.ycombinator.com/item?id=5571937
As a small website owner, are you using TLS? That's the biggest single thing you should be doing - don't worry about DNSSEC.
This depends on what you mean by "small", but IMHO, you don't need DNSSEC. Depending on how small/important your website is, you probably don't even need to bother with DNSCurve either, though you might like to for the fun of it.
Earlier quoted context omitted.
Yahoo did something very much like that about 5 or 6 years ago: inviting me to upload an image file, then telling me to make sure the image is present every time I log in. I upload an image file; the next time I found myself at Yahoo's login prompt, the image file was there; the time after that, it was absent. It has not re-appeared since. Just offering a data point: I don't know enough to have an opinion about the t…
I think he was making a joke. Those pictures do nothing to prevent TLS MITM attacks.