[SSL Observatory] Frequent cert issuers and an estimate for Sovereign Keys protocol alteration bound against DOS

[Phillip Hallam-Baker]

The original SSL protocol has several misconceptions about the way IP
works baked into the protocol. These create operational difficulties that
the CA infrastructure has had to adapt to.

These include the assumption that each different Web server has a
separate IPv4 address. . This led to a demand for certs that could cover
www.example.com and example.com in the same certificate which
seemed perfectly reasonable. Then people realized that the same client code
would accept a cert with altnames for 50 unrelated sites on the same host,
which seems less reasonable. While a proper fix was proposed in the TLS
protocol many years ago the deployment is still lacking

The multiple CNs thing is due to the fact that the early browsers didn't
use SubjectAltName, they used the CN and so there are multiple CNs in
there. Now Rob tells me that this is no longer strictly necessary but views
on necessity may differ in the industry.


 Cloud hosting is really the same as the traditional outsourced
hosting model but with the additional factor that not only does the Web
site not know what else it is sharing a machine with, the machine it is
sharing can (and does) change on an hourly basis. This is essential if
people are going to be able to move their computing costs around to chase
the lowest priced electricity which is going to become increasingly
important as hardware costs reduce to essentially nil and the cost of
electricity is the major remaining cost left. Moving to the lowest cost
power can currently cut electricity costs by 90% at peak, that differential
is going to go up in future with wind, solar etc.

The need to support the use case is a technical constraint that we are just
going to have to live with. But we might have options to make it easier to
process. For example the CA putting more info in the certs so that they can
be recognized as 'the same'.


Another way to look at this problem is that any solution that involves
changes to the server and deploying either a new browser or a plug in has
the same deployment costs as other security controls such as strong
password verification protocols.

On Sun, Dec 4, 2011 at 1:37 AM, Ondrej Mikle <ondrej.mikle at nic.cz> wrote:

> Hi,
>
> I've looked at hosts that send new certs frequently. That is to be
> distinguished
> from 'CDN services' where a server farm sends a couple of certifictes
> depending
> on DNS mapping or load balancer (thus observer sees cert A, then B, ...,
> then A).
>
> An example of frequent issuer (i.e. observation timespans don't overlap,
> cert's
> "not_before" roughly matches first observation time):
>
> Sample 29 certs sent by single host in 71 days period:
>
> http://constructibleuniverse.net/frequent_reissuers/frequent_reissuers.txt
>
> The reason for frequent reissuing is probably that the above certs are
> used for
> some webserver farm (as witnessed by many SANs). I guess each time a new
> FQDN is
> added/removed from hosting, they issue new cert - ones I checked followed
> that
> add/remove SAN/CN patter. Occasionally some get revoked, not sure what's
> their
> criterium for revoking.
>
> There are around 200 such hosts I know of that get new cert issued at
> least once
> every 4 days, on average (all having the same issuing CA).
>
>
> The issuing frequency might be a good lead for setting DOS-protection
> limit of
> allowed protocol changes per time unit in Sovereign Keys implementation
> (original draft had 5 changes per month, IIRC).
>
> One additional consideration for "pinning cert protocols" (DANE, Sovereign
> Keys,
> Auditable CAs, ...) is that such a frequent change must reflect fast to
> relying
> clients. Shouldn't be really a problem, just a point to note.
>
> --
>
> On a side note: while concept of frequent reissuing of certs may not be
> flawed
> per se, though I have a weird feeling about it. Given the number of hosts
> in CNs
> and SANs, it might be easy for human reviewer to miss what is changed (or
> they
> have just good tools to avoid that). Another possibility is that the
> process is
> automated, only automated checks take effect. Any thoughts on how it
> actually
> works? (Their CPS is in French, so couldn't read it).
>
> Side note 2: is there any resolution how to handle multiple CNs in
> certificate's
> Subject? Latest mention I found about multiple CNs was Dan Kaminsky's
> paper/talk
> (2008?) - basically every TLS implementation does something else. Why are
> multiple CNs present/allowed in the first place?
>
> Thanks for bearing this far (sorry for my "compulsive writing" :-))
> Ondrej
>



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111206/a80c05e5/attachment.html>