You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Alex Rukletsov <al...@mesosphere.com> on 2019/05/24 07:25:04 UTC
On augmenting TLS configuration options in libprocess
Folks,
We reviewed TLS configuration options in libprocess and came up with the
following proposal [1] to allow for certificate verification in client mode
only.
In short, the proposal suggests to add two flags to libprocess so that it
can be configured to:
* always require presence and verify server certificates,
* never request client certificates,
* validate hostname using OpenSSL calls.
Please review.
[1]
https://docs.google.com/document/d/1O3q7UOXVGNw81xOkRNFPzrtbC__D-N_D_mwV6D--y0k/edit
Re: On augmenting TLS configuration options in libprocess
Posted by Benno Evers <be...@mesosphere.com>.
Hey,
I just updated the design doc above to v2.0, after we gained some
implementation experience with the original proposal.
As usual, almost none of the initial design survived contact with reality:
While the changes to certificate verification turned out to require less
changes than originally imagined, the hostname validation part became quite
a bit more complicated.
The main reason for that was us discovering that we had not quite
understood the *current* way hostname validation worked in libprocess,
requiring more (and deeper) modifications than anticipated to update it
according to TLS best practices.
The tl;dr of the changes is now this:
* LIBPROCESS_SSL_VERIFY_CERT will be completely ignored in TLS server mode.
* Socket::connect() gains a new optional `peer_hostname` parameter.
* A new libprocess flag `--hostname_validation_algorithm` is added to
select between current and de-crufted hostname validation behaviour.
* UPID gains a new optional `peer_hostname` data member
Cheers,
Benno
On Fri, May 24, 2019 at 9:25 AM Alex Rukletsov <al...@mesosphere.com> wrote:
> Folks,
>
> We reviewed TLS configuration options in libprocess and came up with the
> following proposal [1] to allow for certificate verification in client mode
> only.
>
> In short, the proposal suggests to add two flags to libprocess so that it
> can be configured to:
> * always require presence and verify server certificates,
> * never request client certificates,
> * validate hostname using OpenSSL calls.
>
> Please review.
>
> [1]
> https://docs.google.com/document/d/1O3q7UOXVGNw81xOkRNFPzrtbC__D-N_D_mwV6D--y0k/edit
>
--
Benno Evers
Software Engineer, Mesosphere
Re: On augmenting TLS configuration options in libprocess
Posted by Benno Evers <be...@mesosphere.com>.
Hey,
I just updated the design doc above to v2.0, after we gained some
implementation experience with the original proposal.
As usual, almost none of the initial design survived contact with reality:
While the changes to certificate verification turned out to require less
changes than originally imagined, the hostname validation part became quite
a bit more complicated.
The main reason for that was us discovering that we had not quite
understood the *current* way hostname validation worked in libprocess,
requiring more (and deeper) modifications than anticipated to update it
according to TLS best practices.
The tl;dr of the changes is now this:
* LIBPROCESS_SSL_VERIFY_CERT will be completely ignored in TLS server mode.
* Socket::connect() gains a new optional `peer_hostname` parameter.
* A new libprocess flag `--hostname_validation_algorithm` is added to
select between current and de-crufted hostname validation behaviour.
* UPID gains a new optional `peer_hostname` data member
Cheers,
Benno
On Fri, May 24, 2019 at 9:25 AM Alex Rukletsov <al...@mesosphere.com> wrote:
> Folks,
>
> We reviewed TLS configuration options in libprocess and came up with the
> following proposal [1] to allow for certificate verification in client mode
> only.
>
> In short, the proposal suggests to add two flags to libprocess so that it
> can be configured to:
> * always require presence and verify server certificates,
> * never request client certificates,
> * validate hostname using OpenSSL calls.
>
> Please review.
>
> [1]
> https://docs.google.com/document/d/1O3q7UOXVGNw81xOkRNFPzrtbC__D-N_D_mwV6D--y0k/edit
>
--
Benno Evers
Software Engineer, Mesosphere