Subject: Re: [Trans] [Cryptography] Certificate transparency on blockchains

From: Tom Ritter <[email-masked]>
Date: Thu, 26 Mar 2015 20:18:02 -0500

On 26 March 2015 at 15:45, Greg <[email-masked]> wrote:
> Reading over it, I still have several concerns, which I will voice here but
> let me know if it would be better to also voice them on [trans].

It would be better to voice them on trans, which I am copying.  I
suggest we move it there for follow-ups.

> In Section 3.1.1, it says:
>
> <begin>
>
> HTTPS servers MUST perform a number of sanity checks on SCTs from
>    clients before storing them:
>
>    1.  if a bit-wise compare of the SCT matches one already in the
>        store, discard
>
>    2.  if the SCT can't be verified to be a valid SCT for the
>        accompanying leaf cert, issued by a known log, discard
>
>    3.  if the leaf cert is not for a domain that the server is
>        authoritative for, discard
>
>    Check number 1 is a pure optimisation.  Check number 2 is to prevent
>    spamming and attacks where an adversary can fill up the store prior
>    to attacking a client.  Check number 3 is to help misbehaving clients
>    from leaking what sites they visit.
>
> </end>
>
> Concern #1: Discarding invalid SCTs
> ============================
>
> It is not clear to me what's going on in (2) above.
>
> Specifically:
>
> - How is the server verifying the SCT for validity?

It checks if the signature over the data is valid.

> - Why is the server discarding the SCT if it is invalid?
>
> Wouldn't discarding an invalid SCT totally undermine the point of clients
> sharing them?

Keeping data for an invalid signature (or a signature for a log which
I do not recognize and thus don't have the public key) would allow
clients to store arbitrary data on your server. Complex rate-limiting
and DoS concerns now apply.

> Concern #2: The use of the word SHOULD
> =================================
>
> The doc states:
>
> (with ref to server => auditor comms):
> <begin>
>
> HTTPS servers SHOULD share all SCTs and certificate data they see
>    that pass the checks above
>
> </end>
>
> <begin>
>
> Auditors SHOULD provide the following URL accepting HTTPS POSTing of
>    SCT feedback data:
>
> </end>
>
> <begin>
>
> Auditors SHOULD regularly poll HTTPS servers at the well-known sct-
>    feedback URL.  How to determine which domains to poll is outside the
>    scope of this document
>
>
> </end>
>
>
> As per RFC2119, "SHOULD" means the advice is free to be ignored after the
> implications are "carefully weighed".
>
> This means that so far the document provides no guarantees that a
> misbehaving log will be caught.

Yup. We can't force anyone to participate unfortunately.  A client
_can_ opt-in to using a trusted auditor and send SCTs to them, which
then mitigates the concerns over a server not participating.  But I
will note that if a server does not participate they are essentially
opening themselves to attacks by logs. So they have an incentive to
participate.

> It is also disconcerting that instead of taking direct action themselves,

There is nothing stopping a server from being an auditor and detecting
log misbehavior.  I suppose we could add a note in the draft to that
effect, but it's a pretty weighty option I imagine most people will
not pursue.

> servers are supposed to initiate yet another HTTPS connection to an auditor.

(nit: Server can instead just make the SCTs available for auditors to
query and retrieve from them. Server doesn't have to initiate outbound
requests.)

> This is cumbersome and will probably leave open holes for a global MITM to
> prevent SCTs from reaching auditors, yet again undermining the entire point
> of sharing SCTs.

Yes, an attacker who can persistently isolate a client or server from
the rest of the internet is powerful, and is difficult to defeat. We
do not defend against such an attacker. I'm open to suggestions here,
but none really came to me.

> While it's definitely a positive sign that the sharing of SCTs and
> certificate chains is now an official recommendation, I am concerned that
> the particular implementation is without any teeth to deliver concrete
> results, and so until these concerns are addressed I am not convinced that
> the problem has been fully addressed.

That's fair.  There are limitations to the draft, to be sure - but
balancing the very difficult privacy concerns of literally
broadcasting the websites you've visited is also important.

-tom

---

From: Tao Effect <[email-masked]>
Date: Fri, 27 Mar 2015 00:12:01 -0700

(re-sending from the email I use with [trans].)

Thanks Tom for the very helpful reply.

Thinking this through a bit more, I remember again something that was previously discussed about this technique.

The document does say that clients MUST send the certificate chain back to servers, and that's good, because if that's the case, shouldn't that be enough on its own for servers to detect that a MITM attack occurred (after the MITM leaves)?

If that is so, it seems like a point worth highlighting in the document. It would completely address our concerns about CT's ability to detect MITM attacks post-facto.

Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Mar 26, 2015, at 6:18 PM, Tom Ritter <[email-masked]> wrote:

> _______________________________________________
> The cryptography mailing list
> [email-masked]
> http://www.metzdowd.com/mailman/listinfo/cryptography

---

From: Tao Effect <[email-masked]>
Date: Fri, 27 Mar 2015 11:43:03 -0700

(Changed the thread's subject title to reduce likelihood this question was missed:)

Thanks,
Greg

On Mar 27, 2015, at 12:12 AM, Tao Effect <[email-masked]> wrote:

> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 27 Mar 2015 21:46:37 +0300

Hello all,

On Fri, Mar 27, 2015 at 9:43 PM, Tao Effect <[email-masked]> wrote:

> The document does say that clients MUST send the certificate chain back to
> servers, and that's good, because if that's the case, shouldn't that be
> enough on its own for servers to detect that a MITM attack occurred (after
> the MITM leaves)?
>
> If that is so, it seems like a point worth highlighting in the document.
> It would completely address our concerns about CT's ability to detect MITM
> attacks post-facto.
>
>
I suspect that a smart enough attacker will be able to send native
certificates back to server instead of the ones he sent to client. Or am I
missing something?

Thank you!

> *(re-sending from the email I use with [trans].)*
>
> Thinking this through a bit more, I remember again something that was
> previously discussed about this technique.
>
> The document does say that clients MUST send the certificate chain back to
> servers, and that's good, because if that's the case, shouldn't that be
> enough on its own for servers to detect that a MITM attack occurred (after
> the MITM leaves)?
>
> If that is so, it seems like a point worth highlighting in the document.
> It would completely address our concerns about CT's ability to detect MITM
> attacks post-facto.
>
> Greg
>
> --

-- 
SY, Dmitry Belyavsky

---

From: Paul Wouters <[email-masked]>
Date: Fri, 27 Mar 2015 15:21:15 -0400 (EDT)

On Fri, 27 Mar 2015, Dmitry Belyavsky wrote:

>       The document does say that clients MUST send the certificate chain back to servers, and that's good, because if that's
>       the case, shouldn't that be enough on its own for servers to detect that a MITM attack occurred (after the MITM
>       leaves)?
> 
> If that is so, it seems like a point worth highlighting in the document. It would completely address our concerns about CT's
> ability to detect MITM attacks post-facto.

It is.

> I suspect that a smart enough attacker will be able to send native certificates back to server instead of the ones he sent to client. Or
> am I missing something?

If the attacker fools the client with certificates, it is those
certificates that the client wil send back to the server once
the attacker is gone. It does not matter what the attacker do.

The attacker can forever keep sending whatever certificates
to the server. Once they are no longer attacker the client,
the client will note a different (the real!) certificate
of the server and send its previous (attacker's) certificate
to the server.

Perhaps this can be reflected in an update on the okturtles blog.

Paul

---

From: Tao Effect <[email-masked]>
Date: Fri, 27 Mar 2015 12:43:08 -0700

> Perhaps this can be reflected in an update on the okturtles blog.

That is my intention as soon as I am clear on one more question, prompted by something Dmitry just pointed out.

> the attacker is gone. It does not matter what the attacker do.

I am realizing that this may or may not happen, depending on which part of the TLS handshake these exchanges occur.

To illustrate:

A = server's real certificate
B = malicious MITM certificate

T1. Client receives A.
T2. Client receives B, sends back A.
T3. MITM pretends to leave, sends A. Client sends B.

At T3, if B is handled by MITM _outside and before_ the channel is encrypted by A, then the MITM can prevent the server from seeing B.

So, my question is: does your document properly take that into account and state that the data sent in 3.1.3 *must* be sent after a fully encrypted TLS connection has been established?

Scanning through it, this distinction doesn't seem to be mentioned.

Thanks,
Greg

P.S. FYI Paul, any time I CC your email I get a bounced "Undelivered Mail" response:

Final-Recipient: rfc822; [email-masked]
Original-Recipient: rfc822;[email-masked]
Action: failed
Status: 5.1.1
Remote-MTA: dns; 193.110.157.102
Diagnostic-Code: smtp; 550 5.1.1 <[email-masked]>: Recipient address
   rejected: User unknown in local recipient table

---

From: [email-masked]
Date: Fri, 27 Mar 2015 18:36:56 -0400 (EDT)

> T3. MITM pretends to leave, sends A. Client sends B.

T3 cannot happen. The draft states:

    SCTs and corresponding certificates are POSTed to the originating
    HTTPS server at the well-known URL:

    https://<domain>/.well-known/ct/v1/sct-feedback

This means you must have a valid TLS connection to send the data. As
long as the attacker does not have the private key of the attacked
web server, this cannot happen.

> So, my question is: does your document properly take that into account and state that the data sent in 3.1.3 *must* be sent after a
> fully encrypted TLS connection has been established?

Yes, but I'm sure the authors would love to received improved text for
this section of the document.

>    rejected: User unknown in local recipient table

Sorry about that. I added an alias to fix it. (my home DSL is down so
mail is rerouted temporarily, and I'm far from home)

Paul

---

From: Tao Effect <[email-masked]>
Date: Fri, 27 Mar 2015 16:56:31 -0700

Dear Paul,

This is fantastic news. Great work list!

I am working on a new blog post on this topic to post to the okTurtles blog and am getting ready to publish it.

If you (or anyone else on this list) would like to proof read a draft of it before it's published (sometime today, or tomorrow at the latest), please contact me off-list at this email.

> Yes, but I'm sure the authors would love to received improved text for this section of the document.

I'll see if I can come up with something. :)

Cheers,
Greg

---

From: Tao Effect <[email-masked]>
Date: Fri, 27 Mar 2015 17:28:37 -0700

We've posted a followup blog post:

Certificate Transparency’s improved gossip protocols show promise

https://blog.okturtles.com/2015/03/certificate-transparencys-improved-gossip-protocols-show-promise/

I also updated our previous blog post to make a note of this new information.

Great work folks. 👍

Cheers,
Greg

---

From: Tom Ritter <[email-masked]>
Date: Fri, 27 Mar 2015 20:58:43 -0500

On 27 March 2015 at 19:28, Tao Effect <[email-masked]> wrote:

> *Certificate Transparency’s improved gossip protocols show promise*
>
>
> Great work folks. 

Cool!

I'll add a note: one of the optimizations/tricks we noted while composing
was that a server may actually detect a misbehaving log that it _doesn't_
trust.  Ordinarily we'd discard any such data (because of the
aforementioned problems with DoS and such) - but by looking at the
submitted certificate, and checking if it chains to a root cert in the
store you recognize, you may decide "Actually this one is interesting
enough to keep."  (Still some DoS concerns there, but a trick servers have
the opportunity to work with nonetheless.)

-tom