freebsd security - Dec 2017 - http subversion URLs should be discontinued in favor of https URLs

--------
In message <2a8d9a0a-7a64-2dde-4e53-77ee52632846 at 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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

On Fri, Dec 08, 2017 at 02:07:13PM +0000, Poul-Henning Kamp
wrote:
> --------
> In message <2a8d9a0a-7a64-2dde-4e53-77ee52632846 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20171208/7fef9469/attachment.sig>