On 03/15/2011 02:50 PM, Gil Bahat wrote: > Well, I didn't want to get much into the reasoning but then again I suppose I > can't avoid it. For a short synopsis, I'd say I'm trying to write a mechanism > similar to NSS key log mechanism. > In more detail: > You can see my project listed here: > http://www.cs.tau.ac.il/~benriva/courses/secwsp10a/ > Under 'Improving TLS firewall interception mechanism'. My final intent is to > deliver an in-band encrypted session key. This is an alternative solution to > the firewall doing MITM and so reduces the amount of trust the client needs > to put forth in the firewall - presumably enough to justify passing the key > as part of the exchange. Do you are sending the key in the clear rather than wrapping it in some key for the firewall? Sending the key in the clear lets anyone read it, not just the firewall.
> The merits, pros and cons of the above has been hashed quite a bit as part of > the presentation of the workplan. Since the workplan is committed i'm > focusing on the code and later on may revamp it according to feedback. > > Back to code - this is a modification of the ssl3con.c file and not an > external code, so I'd assume I have access to keys. We purposefully designed NSS to provide enough features to use keys without having access to keys. The provides a couple of things: 1) our SSL implementation can run on FIPS level-3 and level-4 hardware without loosing functionality. Caching, session restart, etc. all continue to work. 2) We don't need to include SSL in crypto validations because SSL never has access to CSPs. 3) When designing new protocols, it keeps us honest. If we can't implement a protocol using the standard wrap, unwrap, encrypt, decrypt, derive, sign, verify operations, then we can ask ourselves what are we doing that's not safe. In your case it seems you need to get some cert or key from the firewall so that you know that only the firewall can snoop and not just anyone on the network. > In particular, NSS key log mechanism from the very same source will output a > plaintext of the pre-master key to a file (line 4595 on my revision). That is debugging code, which only works under certain conditions, and not generally. It's certainly not a feature of NSS (It's not even compiled into shipping versions). > I hope this clarifies the situation better. yes, I would highly suggest you wrap those keys. There are a couple of PK11_ calls that will take a PK11SymKey and wrap it for you. bob > Gil > > -----Original Message----- >> >> and yet... when accessing pwSpec contents - I get nothing. even with >> the speclock. What am i missing? > You are missing the key data. We don't let the application 'just have > it'. Even the SSL engine never sees that actual key data. >> Any help would be appreciated. > Trying to understand what you really want to do would help us in helping > you. > > bob > > >
-- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
