Mandos + CentOS 6
Erik Logtenberg
erik at logtenberg.eu
Sun Jun 29 23:43:06 CEST 2014
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
>
More information about the Mandos-Dev
mailing list