Hi Dave,
On Tue, Aug 25, 2015 at 03:50:23PM +0000, Dave Zhu (yanbzhu) wrote:
> Hey Willy,
>
> On 8/25/15, 10:36 AM, "Willy Tarreau" <[email protected]> wrote:
>
> >This means that the RSA/DSA/ECDSA cert names must be derived from the
> >original cert name.
>
> I¹ve thought of a way to avoid this behavior, with the end result being
> very similar to what you/Emeric proposed.
>
> What if we delayed the creation of the SSL_CTX until we have all the certs
> specified by the config?
In my opinion that only adds extra burden because this delay adds loss of
knowledge or association between the certs that were initially loaded at
the same time.
> We would read in all the certificates first and
> store them based on the CN/SAN inside the cert, or the SNIs specified by
> the admin. We would also store the auxiliary information as well at this
> point. Your tree would look like:
>
> Names -----> Certificates + aux info
>
>
> We then iterate on all of the Names and create an SSL_CTX for each Name
> based on the certificates available + any wildcard/negation filters we
> have. This will fill out our FQDN tree. After creating the SSL_CTX¹s we
> could free the original tree, as it would no longer be needed.
>
> In this scenario, each FQDN would have an SSL_CTX associated with it,
> which is a departure from the current model. While this may seem like a
> huge spike in memory footprint, consider that OpenSSL uses references for
> keys and certificates.
I'm not much concerned by this for now because when you have many FQDN,
you already have as many SSL_CTX today. I tend to consider that large
configs (the ones where memory footprint starts to matter) don't have
many names for each of their certs. For example the config that led to
crt-list being designed was working with 50000 certificates. I really
doubt that there were more than 1-2 names per cert on average, I'd even
bet something around 1.01 or so in average.
> Therefore, the additional impact is limited to the
> extra pointers in SSL_CTX, instead of duplicating X509 or PKEY buffers. We
> could also add additional logic to search through the current FQDN tree
> for ³duplicate² SSL_CTX that contain the same cert/keys, and just use the
> pointer instead of creating a new SSL_CTX. Given enough metadata around
> the SSL_CTX in the FQDN tree, this shouldn¹t be too hard.
That's the part I tend to dislike. If we later add extra parameters in
crt-list, we'll be happy to keep each line separate and *not* to merge
them. The example of validity dates was one such case but there could
be other ones.
While this may seem a stupid or completely made up example, imagine that
we could specify on each line of the crt-list a filter on the source network
to decide if the cert has to be presented or not. This way users could
decide that certs signed with official CAs are delivered to the public
while certs signed with internal CAs are delivered inside. Or even just
to use different algos depending on the network, for example test ECDSA
just on internal users first. As long as we keep all the elements of one
crt-list entry tied together, all such fantasy remains possible. When we
tear them apart and only focus on names to pack everything together, this
is not possible anymore. You said yourself that the memory usage doesn't
matter much here, let's not risk to sacrify extensivity for the sake of
trying to compress just a few more bytes.
> I feel that this would solve the problem of admins having to keep track of
> the certificate names, and keep the current behavior of ³Let HAProxy
> figure out the certs, here¹s a bunch of them².
>
> It would also solve the issue of conflicting names. For example:
>
> Cert A(RSA):
>
> CN: www.blahDomain.com
> SANs: 1.blahDomain.com
> 2.blahDomain.com
> 3.blahDomain.com
>
> Cert B(ECDSA)
>
> CN: www.blahDomain.com
>
> SANs: 2.blahDomain.com
> 3.blahDomain.com
> 4.blahDomain.com
>
>
> If we optimize the insertion logic via metadata, we would have the
> following in our FQDN tree:
>
> 1: Name=www.blahDomain.com; SSL_CTX#1={Cert A, Cert B}
> 2: Name=1.blahDomain.com; SSL_CTX#2={Cert A}
>
> 3: Name=2.blahDomain.com; SSL_CTX#1={Cert A, Cert B}
>
> 4: Name=3.blahDomain.com; SSL_CTX#1={Cert A, Cert B}
>
> 5: Name=4.blahDomain.com; SSL_CTX#3={Cert B}
>
>
> Like your proposal, we would have 3 distinct SSL_CTX¹s in memory, and 5
> entries in the FQDN table.
In the case I proposed, it would be exactly the same, without requiring to
merge all of them by name between different lines.
> If the admin specified multiple certificates and wildcards that met the
> same criteria, we would have to decide on which cert goes into the SSL_CTX
> for that FQDN. My personal preference is to use the explicit before the
> wildcard, but either way the logic would not be difficult.
That's why I prefer not to change the existing selection logic which is
documented and deployed. Also, please keep in mind that changing anything
here is really vicious because issues may happear days or weeks after the
code change, just because some tricky setups were deployed and happened to
work before the update. We definitely need to make users not lose trust in
the product if it has been working well for a year or so for them.
But overall, I think we're all aiming towards more or less the same directions
and coming to comparable conclusions after identifying the same problem, which
is encouraging!
Thanks,
Willy
