Mandos + CentOS 6

[Erik Logtenberg]

Hi,

Has there been any further progress on getting Mandos to work with
RHEL/Fedora/CentOS?

Thanks,

Erik.


On 04/13/2014 06:23 PM, Teddy Hogeborn wrote:
> "Nathanael D. Noblet" <nathanael at gnat.ca> writes:
> 
>>>>> As far as I know, OpenSSL can not use OpenPGP keys, and at the
>>>>> time I investigated, GnuTLS was the only TLS library to support
>>>>> it.  I also seem to recall that OpenSSL has a problematic
>>>>> license which precludes us from using it.
>>>>
>>>> So out of curiosity - why opengpg certificates + TLS?
> [...]
>>> The OpenPGP key serves an important security function.
> [...]
>>> For more details, see the section called NETWORK PROTOCOL in
>>> mandos(8).
>>>
>>> I hope it is clear why conventional domain-name-based X.509
>>> certificates would be completely inappropriate here.
>>
>> So I think I understand the above, however as far as I'm aware you can
>> have two way verification of x.509 certificates. The server verifies
>> the clients certificate and the client only provides its certificate
>> to valid servers. Which essentially provides the same security as
>> above.  With certificates signed by a trusted CA (which can be an in
>> house CA).  The server makes sure that the certificate provided is
>> trusted and then gets the client name from the certificate details
>> (which can't be forged and still have a valid certificate if I'm not
>> mistaken). I don't see much difference between that and the OpenPGP
>> certificate method. Am I wrong?
> 
> No, I think your proposed scheme would basically work.  It has, however,
> a few issues:
> 
> 1. Clients would need to arrange for their X.509 certificates to be
>    signed by a CA which the Mandos server trusts.  This is an additional
>    complication not needed with the existing protocol.
> 
> 2. You say that "[...] the client only provides its certificate to valid
>    servers.".  Why?  This additional step could probably be added to the
>    existing protocol, but what additional security does it provide?
>    What attack does it prevent?
> 
> 3. Your proposed scheme uses X.509 certificates.  These are
>    fundamentally unsuitable for our purposes due to:
>    
>    a) Their main orientation towards certificate authority signing
>       chains.  We do not use this feature in Mandos, so there is every
>       reason to prefer the simpler OpenPGP keys instead.
>    
>    b) The enormous complexity of X.509.  See here for more details:
>       <https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf>
>       This complexity has lead to very many bugs in a lot of software
>       over the years, including Apple's recent "goto fail" bug.
>    
> 4. "GPG for data at rest. TLS for data in motion." is a rather well-
>    known quote by Thomas Ptacek in a dialog he wrote about best
>    practices in cryptography: <http://e-x-a.org/articles/typing-a-e-s/>
>    If we want to follow that principle, we should encrypt the data with
>    OpenPGP when it is "at rest" in the Mandos server.  This means the
>    client needs an OpenPGP key *anyway* to decrypt this data.  So we
>    already have an OpenPGP key to use in the TLS connection.  Using an
>    additional X.509 certificate for the TLS connections seems
>    nonsensical given that TLS already supports OpenPGP keys.
> 
> Also, we designed the protocol to use OpenPGP keys because we *like*
> OpenPGP keys, and we wrote the program to use GnuTLS because we *like*
> GnuTLS - and that is only partly because it supports OpenPGP keys in
> TLS.
> 
> We have, so far, managed to avoid *all* major bugs in TLS libraries that
> have been released in recent years.  We use GnuTLS, which is not subject
> to the Heartbleed bug or to the "goto fail" bug, and the recent bug *in*
> GnuTLS bug only affected verification of X.509 certificates.  Therefore,
> I feel irrationaly pleased with our intuitive choices of technologies
> and libraries.
> 
> /Teddy Hogeborn
>