With regards to sending the key as plaintext - that's just in the interim, once
I get that successfully done I will write the code to encrypt it. Besides,
before I can wrap the key, I'd still need to pass the raw representation as a
parameter, so I'm trying to get that first.
With regards to key access - what would be the right way to do it then? I want
to reliably access the session key and then dump it as soon as I don't need it.
On a somewhat related note, I don't think I understand the purpose of this code
snippet from ssl3con then:
pwSpec->client.write_key =
PK11_SymKeyFromHandle(slot, symKey, PK11_OriginDerive,
bulk_mechanism, returnedKeys.hClientKey, PR_TRUE, pwArg);
shouldn't this set some form of value to pwSpec->client.write_key - plaintext
or encrypted? Why would I get nulls when accessing this data structure?
-----Original Message-----
From: Robert Relyea [mailto:[email protected]]
Sent: Wednesday, March 16, 2011 12:52 AM
To: Gil Bahat
Cc: mozilla's crypto code discussion list;
[email protected]
Subject: Re: Need assistance - how can pwspec write key length be 0 after the
client key exchange?
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
