[Ach] StartSSL for Business Sysadmins

Andreas Mirbach a.mirbach at me.com
Sun Jan 12 19:40:21 CET 2014


I totaly agree with you. X.509 is a fundamentaly broken system but it is currently the most common system on the internet. And this dokument won't change it.

And i agree that we should not do marketing for vendors. 

Andreas Mirbach

Sent from my iPad

> On 12.01.2014, at 19:16, Aaron Zauner <azet at azet.org> wrote:
> 
> It's one thing to explain how X.509 and so forth work, another to tell people how to use the website of a CA and which CAs are out there. I agree that the section on CAs is pretty small and needs some improvement - but we should neither do marketing for vendors nor assume that our readers have no understanding about system administration. After all, that's pretty basic stuff, right?
> 
> Full disclosure: IMHO X.509 is a bullshit protocol for online trust. You can't have a network comprised of autonomous systems relying on a hierarchical trust structure that provides higher up levels in the chain zero confirmability for authenticity or security. meaning - as recent history has shown and academia told us long ago - a CA can be compromised easily, can issue faulty certificates or issue certs for sub-CAs that will be, because of the chaining, instantly trusted by any browser or client. These facts have been exploited widely, with CAs giving some companies sub-CAs to man-in-the-middle SSL/TLS traffic of employees surfing. And that's just one example. Most CAs do not even get the Key Usage flag of their certificates right, which is why some software implementations dealing with X.509 chose to simply ignore it. This field is used to state WHAT the certificate is actually meant to be used for. I think it's long overdue to replace this piece of shit. It's complicated, was designed for telephony indices, has a lot of weaknesses and no means for provable authenticity or security as it's used and deployed today. We'd need something like a decision protocol where a majority of clients/servers using the protocol vote if a actor (service, server, company) is trustable. Propagation and updating of information might be an issue, I've not yet found a good solution for that, neiter for networks that are very small and not connected to the internet. There are papers and some software implementations on protocols like that, I think they could be used as a replacement if done well.
> 
> 
> 
> 
> 
>> On Sun, Jan 12, 2014 at 6:41 PM, Andreas Mirbach <a.mirbach at me.com> wrote:
>> Okay got it.
>> Have you reviewed my poll fot the iis section?
>> Can i help with some testing in this section?
>> 
>> Sent from my iPad
>> 
>> > On 12.01.2014, at 18:35, "L. Aaron Kaplan" <kaplan at cert.at> wrote:
>> >
>> >
>> >> On Jan 12, 2014, at 6:24 PM, Andreas Mirbach <a.mirbach at me.com> wrote:
>> >>
>> >> Hi Aaron,
>> >>
>> >> in my opinion a security guide that discuss just a view cipher oders has no value at all. The document title is applied crypto hardening and it is aimed to be a copy and paste reference for sysadmins. In an "applied" real world scenario there are CAs involved in the crypto chain. It is essential to understand crypto security as a process of many things come and work together. It's not just some console commands and the use of commonly thusted ciphers.
>> >
>> > Andreas,
>> >
>> > you might be right but in the beginning we had to make some decisions what is "in scope" in the first version and "out of scope" and might be put into a later version or a different document (which of course should be referenced).
>> >
>> > At that time, we all looked at the PKI issues and were saying to ourselves: "if we document all that we are never going to be finished " ;-) That's why became "out of scope" for the first version.
>> >
>> >> I agree with you that this i maybe a topic for a second document.
>> >
>> > :)
>> >
>> > ACK
>> >
>> >
>> > ---
>> > // L. Aaron Kaplan <kaplan at cert.at> - T: +43 1 5056416 78
>> > // CERT Austria - http://www.cert.at/
>> > // Eine Initiative der nic.at GmbH - http://www.nic.at/
>> > // Firmenbuchnummer 172568b, LG Salzburg
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Ach mailing list
>> > Ach at lists.cert.at
>> > http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>> _______________________________________________
>> Ach mailing list
>> Ach at lists.cert.at
>> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
> 
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140112/41e1e6bd/attachment.html>


More information about the Ach mailing list