[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 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?

 [0]: Instead of doing X509_STORE_add_cert() we will have to do
 SSL_CTX_add_extra_chain_cert(), so that the invalid cert. chain gets
 presented during v1. And in the case of a v2, we will have to dive into
 the guts of OpenSSL and remove the cert from the SSL context ourselves,
 before re-adding it in the renegotiation stage. Sounds *very* ugly.
 http://osdir.com/ml/encryption.openssl.cvs/2003-02/msg00032.html

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4549#comment:8>
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