SoylentNews is people
SoylentNews
Popular Bash shell script LetsEncrypt.sh, which is used to manage free SSL/TLS certificates from the Let's Encrypt project, has renamed this week to avoid a trademark row. This comes in the wake of Let's Encrypt successfully fending off Comodo, which tried to cynically snatch "Let's Encrypt" for itself.
LetsEncrypt.sh, written by Germany-based Lukas Schauer, is now known as Dehydrated. If you have scripts or apps that rely on pulling in his code and running it, they may stop working as a result of the name change. Dehydrated is developed independently by Schauer and is not officially affiliated with Let's Encrypt.
"This project was renamed from letsencrypt.sh because the original name was violating Let's Encrypt's trademark policy. I know that this results in quite a lot of installations failing but I didn't have a choice," reads the new Dehydrated README.
[...] Full disclosure: This article's author uses Let's Encrypt to provide HTTPS encryption for his personal websites. And you should use it too.
Our Previous Story: 800-Pound Comodo Tries to Trademark Upstart Rival's "Let's Encrypt" Name
(Score: 4, Interesting) by NCommander on Monday September 19 2016, @09:25PM
Ad networks dislike SSL because it drastically increases page loading times since browsers need to check revocation. If any inline asset fails, older browsers will pop a warning box (more recent chrome/firefoxes just silently refuse to load the content).
The fact is self-signed certificates actually should be rejected by default; SSL by definition means that both encryption and the host are authenticated. A self-signed certificate by definition can't provide the later; as much as CAs suck, they generally do at least make it harder to fake the later; had DANE not crashed and burned, the situation would be much better. A bigger problem is the fact that there's no realistic way to do opportunistic encryption with HTTP and the IETF failed very hard by failing to define it for HTTP/2 (which would have made that protocol actually be somewhat useful).
A proper solution to the problem is have "degrees of trust" that determine if a certificate is trusted. For example, let's assume you trust a cert at 3 points of trust
- Valid CA signature +1 points
- Valid OCSP response: +1
- Valid DANE record +2
- HTTP Key Pinned* +2
- Certificate Transpency check passed +1
* - at least if this spec was not completely broken
Unfortunately, right now, its all or nothing. I've looked into Mozilla's security forums and there's not much desire to embrace DANE or other technologies. HPKP is gaining some traction, but I dislike it because its very easy to brick a website by accident without recovery due to the way the pins work. Pinning should never be done via an in-bound method because of this and of any/all implementations of SSL pinning that I'm aware of, only HPKP actually does it in-band. It's primarily the reason its not been deployed on SN.
Still always moving