Unmitigated Risk

My post responding to this - https://unmitigatedrisk.com/?p=552

For folks discovering this: Unfortunately, this isn’t a good idea, and can seriously harm your system. I’ll be the first to tell you that I believe Google and Mozilla have done a lot for supervising TLS, but realize that the trust stores contain many other non-TLS purposes, and with the CAs constrained from TLS issuance (e.g. only trust for S/MIME). CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab You can see a little bit about this at https://github.com/crtsh/certwatch_db/issues/69 and http://unmitigatedrisk.com/?p=259 Approaches like the OP link fail to take that into consideration, and can easily break core OS services, non-TLS cases like code signing or S/MIME, or even reintroduce trust in CAs that Microsoft has programmatically disabled.

If you want to go straight to the code you can find it at https://github.com/merklecounty/rget#rget My initial target with the project is to onboard a couple of popular GitHub projects. And because of my experience with etcd and Kubernetes I am starting with those two: https://github.com/kubernetes/kubernetes/issues/70132#issuecomment-518… https://github.com/etcd-io/maintainers/issues/16 This is an interesting problem space that I think people are starting to really dig into and build systems around. For example the Go community is working on a similar log for their federated library package system: https://blog.golang.org/modules2019 Also, here is a good post on the topic in general as well: http://unmitigatedrisk.com/?p=636

Hello! That's very true, thanks to Maxim Dounin from Nginx[1] And Ryan Hurst[2] from GlobalSign Making SSL faster is really important to be able to support "full https" websites, with HSTS headers[3] and Alternate-Protocol: spdy[4][5] full disclosure, I do work for CloudFlare and on this particular feature :) [1]http://nginx.com/news/nginx-ocsp-stapling.html [2]http://unmitigatedrisk.com/?p=100 [3]http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [4]http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Se… [5]http://blog.cloudflare.com/introducing-spdy [6]ngxlua.org