[liberationtech] self signing certs by default

[John Adams]

How optimistic you are around the way SSL works. If I can make a cert and you have no 3rd party to verify against, anyone can be anyone.

Forging DHCP lets me forge DNS and own you. 

This "apparatus" which you believe can be "difficult to deploy" and "easy to reveal" is entirely not of that nature.


Sent from my iPhone

> On Mar 14, 2014, at 17:08, Lucas Gonze <lucas.gonze at gmail.com> wrote:
> 
> The MITM is much more expensive, so would make it unfeasible to maintain current levels of surveillance.
> 
> The MITM can't be done in secrecy. The client can publish the certificate that it received. This would force the surveillance apparatus to reveal itself.
> 
> 
>> On Fri, Mar 14, 2014 at 2:45 PM, John Adams <jna at retina.net> wrote:
>> You misunderstand the signing practice if you think this is a good idea.
>> 
>> Granted, it provides a low level of encryption for clients but it does not provide Non-repudiability to those users, opening them up to MitM attacks.
>> 
>> Sent from my iPhone
>> 
>> > On Mar 14, 2014, at 16:35, Guido Witmond <guido at witmond.nl> wrote:
>> >
>> >> On 03/14/14 19:56, Julian Oliver wrote:
>> >> ..on Fri, Mar 14, 2014 at 10:46:30AM -0700, Lucas Gonze wrote:
>> >>> Let's say web servers auto generated self-signed certificates for any
>> >>> domain that didn't supply its own certificate, likely one from an authority.
>> >>>
>> >>> What that would accomplish is to make the stream unreadable over the wire,
>> >>> unless the attacker was willing and able to do an MITM with their own auto
>> >>> generated self-signed certificate.
>> >>>
>> >>> It would not be hard to do that MITM, but it would be orders of magnitude
>> >>> more expensive than copying unencrypted bytes off the router. It would not
>> >>> be practical to do the MITM against a large portion of traffic. The
>> >>> attacker would have to pick their targets.
>> >>
>> >>>
>> >>> Thoughts?
>> >
>> >>
>> >> It would be good if Debian and other popular GNU/Linux LAMP distributions made
>> >> OpenSSL/TLS key generation (and set up of a VirtualHost template for :443) an
>> >> encouraged option during an Apache installation (OpenSSL is a dependency
>> >> anyway). It could be a simple walkthrough with Qs for CN and admin email,
>> >> abstracting over the classic and ungainly:
>> >>
>> >>    openssl req -new -x509 -days 365 -nodes -out /etc/ssl/localcerts/apache.pem -keyout /etc/ssl/localcerts/apache.key
>> >
>> > One could also automatically derive the DNSSEC-DANE TLSA record from
>> > that server certificate and mail it to the sysadmin. Include a paragraph
>> > that explains that by publishing that record, the site has stronger
>> > protections against MitM-attacks than possible with CA-bought certificates.
>> >
>> > (the downside is that user need to install the Extended-DNSSEC-Validator
>> > plug in).
>> >
>> >
>> >
>> > Regards, Guido.
>> >
>> > --
>> > Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu.
>> --
>> Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu.
> 
> -- 
> Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140314/d776be51/attachment.html>