Re: exposing certificate information (current + upcoming)

On 2019/05/21 22:39, Stefan Eissing wrote:
> Just FYI: https://github.com/icing/mod_md#certificate-status

> 
> for a description of the current implementation. Moved it underneath /.httpd
> for now since I am too lazy to write a draft for /.well-known/...

If it's the case that things like the above happen because some people 
see the registration requirements for .well-known as too exacting, then 
I think we have made a mistake. .well-known shouldn't become something 
that gets avoided because the registration requirements are too high.

We have had similar discussions e.g. for mime media types, URI 
schemes,... in the past, and we should have learned something from them.

Regards,   Martin.

>> Am 11.05.2019 um 14:37 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
>>
>> As I understood Christophs use case, he wants to monitor CT logs for newly issued certificates for any domain of his. To verify that the new certificate was indeed obtained by one of his servers/devices he would like to ask them.
>>
>> If the server does not list the cert as incoming, someone else might have spoofed the CA into issueing it.
>>
>> This helps if a new cert is not immediately activated on the device running ACME. A delay of such activation is practically 0 on many servers, but can extend to days on others. With Apache, it is controlled by the admin. A server with several hundred or thousands hosted domains will aggregate restarts most likely, for example.
>>
>> The idea of an automated domain monitor that can warns you within a short time that a renewal was not done by the box handling the domain, seems legit.
>>
>> - Stefan
>>
>> Am 10.05.2019 um 19:48 schrieb Ryan Sleevi <ryan-ietf@sleevi.com>:
>>
>>>
>>>
>>> On Fri, May 10, 2019 at 6:50 AM Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>>> Christophe Brocas (@cbrocas), organizer of Pass-the-Salt security conference, tweeted
>>> about checking HTTP server certificates against CT logs to detect very early if someone
>>> successfully highjacked one of your domains.
>>>
>>> A renewed certificate is often not immediately used on a server but activated on the
>>> next restart which can be several hours away. To check if a certificate mentioned in a
>>> CT log, one would need to obtain information about upcoming certificates as well.
>>>
>>> I'm not sure I understand the CT use case. Are you attempting to verify that a certificate with embedded SCTs has been incorporated within a logs MMD? The discussion of detecting very early if someone hijacked one of your domains seems largely orthogonal to providing information about your present certificate, since the attacker/adversary would simply not provide this information. In CT, this is fine, because the reliance is upon the SCTs (whether from TLS, embedded, or OCSP) being proof of inclusion within a log, and, as Ilari mentioned, client verification and/or gossip of those SCTs (and related STHs) to ensure presence within a log.
>>>
>>> While I don't think there's any harm in exposing information about upcoming certificates, particularly if they've already been logged (by the server, in the case of TLS, or by the CA, in the case of embedded SCTs or OCSP responses), it doesn't seem to fit with a very clear threat model, and I worry I'm missing something that's supposed to be obvious here.
> 

Received on Wednesday, 22 May 2019 09:02:56 UTC