[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4549 [Tor Bridge]: Implement user-defined certificate strings through torrc (part of the proposal 179 efforts)
#4549: Implement user-defined certificate strings through torrc (part of the
proposal 179 efforts)
------------------------+---------------------------------------------------
Reporter: asn | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Tor Bridge | Version:
Keywords: | Parent: #3972
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by nickm):
Replying to [comment:8 asn]:
> Replying to [comment:3 nickm]:
> > * It looks like you apply the issuer name stuff to be the name of
EVERY issuer, and the subject name to be subject name on EVERY cert? That
isn't right, if so. This stuff only wants to apply to the initial
presented-in-cleartext cert, which now wants to be different from the cert
chain presented after in the v2 or v3 handshake. The cert chain probably
wants to stay unchanged.
>
> Hm, what about the v1 handshake? There, the 'presented-in-cleartext
certificate' has to be passed along with the 'identity certificate'. This
means that in the v1 case, we have to customize the 'identity certificate'
with the user-defined certificate strings so that the certificate chain
remains valid with:
> `cleartext_cert.issuerDNs == id_cert.issuerDNs == id_cert.subjectDNs`
>
> I don't consider this necessarily wrong, since it seems logical from a
PKI PoV.
>
> If we do this, the 'link certificate' is equal to the 'presented-in-
cleartext certificate', since we will also need to customize the 'link
certificate' to form a valid certificate chain with the customized
'identity certificate' during the v2 renegotiation.
> This probably means that we don't need an extra 'presented-in-cleartext
certificate' and we can simply customize our 'link certificate'.
>
> If we don't want to do this, we will have to either kill the v1
handshake (we probably don't like this), or we will have to change the
logic with which we create our certificate chains since OpenSSL will not
present a non-valid certificate chain during the SSL handshake [0]. Both
solutions seem *much* dirtier than customizing all the certificates that
need to be customized.
>
> I believe that if a user has provided certificate strings, we have to
customize all our SSL context certificates so that they make sense from a
PKI point of view (and so that all of our handshakes work correctly.).
What do you think?
Ah, okay. I think I'm convinced that all the certs probably need to have
new names in them, if we're going to keep v1 alive (which we are for now).
But part of my original point stands, though: when there's a 2-cert chain,
we need to have the issuerDN of the link cert match with the subjectDN of
the identity cert. I *believe* that your original patch did that oddly,
and instead gave all certs the same issuerDN and all certs the same
subjectDN.
So here's what I'd suggest:
Let the user configure an issuerDN "I" and a subjectDN "S".
When there's just one cert presented in plaintext, it should probably look
self-signed. So it should have issuerDN=subjectDN=S. When there are two
certificates, the link cert should have issuerDN=I and subjectDN=S, and
the identity cert needs issuerDN=subjectDN=I.
Does that work out?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4549#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs