On Fri, Dec 08, 2017 at 02:07:13PM +0000, Poul-Henning Kamp wrote: > -------- > In message <2a8d9a0a-7a64-2dde-4e53-77ee52632...@tjvarghese.com>, TJ Varghese > w > rites: > > >I'm curious as to your take on electronic banking. > > Good security is not "all or nothing", it is a carefully calibrated > application of security measures to the problem at hand. > > By forcing all web-traffic onto HTTPS, the rabid IT-liberalist has > put governments in a position where they either have to break HTTPS > traffic open or give up on having a working criminal justice system. > > Anybody with a daughter knows what that dice will roll. > > If you've ever read Clausewitz, you will recognize this strategy > as really stupid: *Never* put your enemy in a position where their > only option is to defeat you. > > Various governments are going about this in different ways, some > force a trojan root-cert on all their citzens, others pass law > where you can be jailed indefinitely until you hand over your > passwords, others again try force the IT-industry to "ensure > legal access". > > Unfortunately this happens with little or no intelligent and > cooperative input from the IT-community, who seem hell-bent > on their "all or nothing" strategy. > > I personally preferred it back when HTTPS was tolerated by governments, > because everybody could see that banking and e-commerce needed it, > over the situation now, where HTTPS is so trojaned, that my webbank > is no longer trustworthy via HTTPS.
It really is a sad state that governments feel they must subvert secure communications channels used by citizens. I agree with you there. Please note that this is likely to be my only contribution to this thread. What if FreeBSD generated its own CA for use with critical infrastructure, like the svn repo. The trusted CA certificate would be distributed via multiple means: in the src tree and on the website. It would get installed on user's systems. The CA cert could have a long lifetime, say twenty years. FreeBSD would use key material generated by its CA to secure the comms channel for the critical infrastructure. This key material would have a significantly shorter lifetime, perhaps six months or one year. Thus, the private key material for the CA only needs to come out of cold storage to generate new key material only periodically (hence why the CA cert can have a long lifetime). This would accompish multiple goals: 1. It would secure the comms channels for critical infrastructure. 2. It would prevent FreeBSD from being tied to existing CAs, which could be compromised or coerced into misbehaving. 3. It keeps FreeBSD in full control of their infrastructure. FreeBSD already distributes key material for use with pkg (and perhaps freebsd-update and portsnap (I don't know how those two work under-the-hood with regards to dsigs)). Distributing one more piece of key material isn't going to create much overhead. We at HardenedBSD use a similar method as proposed above for our binary updates. We use X.509 certificates to create a chain of trust for our binary updates for base. We maintain our own CA, with the CA cert having a lifetime of twenty years. The key material used to sign the update gets regenerated every year on January 1st, but has a thirteen-month lifespan. The CA key material resides on an encrypted flash drive, stored in a place that requires two signatures from two parties and two physical keys, only one of which I hold. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
