Why SSLClientSocketNSS didn't do any encrypt or decrypt operations?

[makefish]

1,
Hi, In http://www.chromium.org/developers/design-documents/network-stack/ssl-stack,
it tells Chromium will switch to NSS for SSL.in all platforms.

But in the following two functions, I found they didn't any encrypt or
decrypt operations:
/**********************************************************/
SSLClientSocketNSS::Write
SSLClientSocketNSS::DoPayloadWrite
/**********************************************************/
SSLClientSocketNSS::Read
SSLClientSocketNSS::DoPayloadRead
/**********************************************************/

In contrast to NSS, the SSLClientSocketWin implemention of windows
did encrypt & decrypt by EncryptMessage &
DecryptMessage:
/**********************************************************/
SSLClientSocketWin::DoPayloadEncrypt
EncryptMessage
/**********************************************************/
SSLClientSocketWin::DoPayloadDencrypt
DencryptMessage
/**********************************************************/

So does it mean that the SSL support of NSS was not fully
implemented ?

2, In the same link, it tells chromium will "Continue to use the
system crypto library for crypto and certificate verification."
What does the "system crypto library" stand for ?


Any hints will be welcome!

[Ryan Sleevi]

On Mon, Feb 6, 2012 at 11:17 PM, makefish <open...@gmail.com> wrote:

1,
Hi, In http://www.chromium.org/developers/design-documents/network-stack/ssl-stack,
it tells Chromium will switch to  NSS for SSL.in all platforms.

Apologies, that design doc is somewhat out-dated - the features described have long since been implemented, initially during the Chrome 6 development phase for most purposes, and finalized for all uses prior to the release of Chrome 9.

Chromium currently uses NSS for SSL across all platforms, while still using the appropriate platform-specific routines for performing certificate validation, consistent with what that design doc said would be implemented.

 

But in the following two functions, I found they didn't any encrypt or
decrypt operations:
/**********************************************************/
SSLClientSocketNSS::Write
SSLClientSocketNSS::DoPayloadWrite
/**********************************************************/
SSLClientSocketNSS::Read
SSLClientSocketNSS::DoPayloadRead
/**********************************************************/

In contrast to NSS, the SSLClientSocketWin implemention of  windows
did encrypt & decrypt by EncryptMessage &
DecryptMessage:
/**********************************************************/
SSLClientSocketWin::DoPayloadEncrypt
EncryptMessage
/**********************************************************/
SSLClientSocketWin::DoPayloadDencrypt
DencryptMessage
/**********************************************************/

So does it mean that the SSL support of NSS was not fully
implemented ?

No, it just means that the APIs are different.

EncryptMessage and DecryptMessage are two functions that are specific to the Win32 way of implementing a TLS client. You could compare them to the SecureTransport implementation on OS X's ssl_client_socket_mac.cc that uses SSLRead()/SSLWrite(), which is a different API that accomplishes the same thing.

For more information about NSS and its API, consider reading the documentation at http://www.mozilla.org/projects/security/pki/nss/ which provides more information.

While the actual cryptographic algorithms and TLS protocol implementations are best discovered by reading the above documentation, the Chromium-specific patch to allow NSS to interact with the system client certificate stores, as referenced in that early/out-dated design doc, is located at http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/clientauth.patch?revision=HEAD&view=markup

2, In the same link, it tells chromium will "Continue to use the
system crypto library for crypto and certificate verification."
What does the "system crypto library" stand for ?

Just what it says. Both Windows and OS X have OS-supplied APIs for performing certificate validation. These APIs are provided and maintained by Microsoft/Apple, implement varying degrees of specifications/Internet standards, and provide a way for developers writing applications targeting these particular OSes to validate certificates and chains with varying constraints.

On Windows, this is provided through the broad set of APIs collectively referred to as CryptoAPI, although Microsoft typically defines CryptoAPI as just a small subset of those APIs ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa380255(v=vs.85).aspx ). On OS X, this is provided through the set of APIs exported by Security.framework, which includes Keychain Services and Certificate, Key and Trust services ( https://developer.apple.com/library/mac/#documentation/Security/Conceptual/CertKeyTrustProgGuide/01introduction/introduction.html#//apple_ref/doc/uid/TP40001358 )

Given the nature of your questions, can I ask about your motivations and interest in the Chromium SSL stack? Are you considering adapting it for a project of yours? 

The particular path that Chromium has gone, with the hybrid SSL/TLS layer from NSS backed by the underlying OS cryptographic APIs, is certainly a very esoteric case, and not one that is really comfortably supported by either Microsoft or Apple and their public APIs. While it works for Chromium's needs/concerns, it's not something that should be embraced lightly, as there still remain a few sharp edge cases that don't really work as well for end-users as one might hope.

If you're looking for more information, I'd encourage you to download and browse the code, particularly the code in src/net/base/ . Additionally, you can use Google Code Search via http://cs.chromium.org to quickly search references in the code, which should hopefully be fairly thoroughly documented.

Cheers!

[makefish]

Thanks Ryan!
But I cann't find any encrypt and decrypt in SSLClientSocketNSS::Write
and SSLClientSocketNSS::Read.
In Win 32, they do use win32 api EncryptMessage and DencryptMessage
to do encrypt and decrypt.

As you say , NSS uses a different api. But which Api is it ? I read
the source of SSLClientSocketNSS but i didn't find it.

By the way, I am just a crazy boy who has greatest interest in
Chromium and Google.
I have been keeping reading and analyzing the source code of chromium/
Webkit for two years.







On Feb 7, 4:54 pm, Ryan Sleevi <rsle...@chromium.org> wrote:

> On Mon, Feb 6, 2012 at 11:17 PM, makefish <opensp...@gmail.com> wrote:
> > 1,
> > Hi, In

> >http://www.chromium.org/developers/design-documents/network-stack/ssl...
> > ,

> located athttp://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/p...

>
> 2, In the same link, it tells chromium will "Continue to use the
>
> > system crypto library for crypto and certificate verification."
> > What does the "system crypto library" stand for ?
>
> Just what it says. Both Windows and OS X have OS-supplied APIs for
> performing certificate validation. These APIs are provided and maintained
> by Microsoft/Apple, implement varying degrees of specifications/Internet
> standards, and provide a way for developers writing applications targeting
> these particular OSes to validate certificates and chains with varying
> constraints.
>
> On Windows, this is provided through the broad set of APIs collectively
> referred to as CryptoAPI, although Microsoft typically defines CryptoAPI as

> just a small subset of those APIs (http://msdn.microsoft.com/en-us/library/windows/desktop/aa380255(v=vs...

> ).
> On OS X, this is provided through the set of APIs exported by
> Security.framework, which includes Keychain Services and Certificate, Key

> and Trust services (https://developer.apple.com/library/mac/#documentation/Security/Conce...

>  )
>
> Given the nature of your questions, can I ask about your motivations and
> interest in the Chromium SSL stack? Are you considering adapting it for a
> project of yours?
>
> The particular path that Chromium has gone, with the hybrid SSL/TLS layer
> from NSS backed by the underlying OS cryptographic APIs, is certainly a
> very esoteric case, and not one that is really comfortably supported by
> either Microsoft or Apple and their public APIs. While it works for
> Chromium's needs/concerns, it's not something that should be embraced
> lightly, as there still remain a few sharp edge cases that don't really
> work as well for end-users as one might hope.
>
> If you're looking for more information, I'd encourage you to download and
> browse the code, particularly the code in src/net/base/ . Additionally, you

> can use Google Code Search viahttp://cs.chromium.orgto quickly search

[Ryan Sleevi]

On Tue, Feb 7, 2012 at 1:29 AM, makefish <open...@gmail.com> wrote:

Thanks Ryan!
But I cann't find any encrypt and decrypt in SSLClientSocketNSS::Write
and SSLClientSocketNSS::Read.
In Win 32, they do use win32  api EncryptMessage and DencryptMessage
to do encrypt and decrypt.

As you say , NSS uses a different api. But which Api is it ? I read
the source of SSLClientSocketNSS but i didn't find it.

DoPayloadRead() calls PR_Read(), and DoPayloadWrite() calls PR_Write(). These are the functions that handle encryption and decryption.

For a better understanding of how SSLClientSocketNSS is implemented, I would again encourage you to check out the NSS documentation. For example, http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslintro.html details a bit about a general functions involved with an SSL client using NSS. As you read through the source of SSLClientSocketNSS, you'll see it calls quite a few of these functions.

For more information about NSS and using it in client applications, a more suitable group would be Mozilla's dev.tech.crypto mailing list, which is also available via Google Groups at http://groups.google.com/group/mozilla.dev.tech.crypto/topics

Cheers!

[makefish]

Ryan, You are right. The PR_Read/PR_Write will eventually call:
ssl_Read, /* read */
ssl_Write, /* write */

At first I also think PR_Read/PR_Write will do the encrypt&decrypt.
But after reading the explanation of https://developer.mozilla.org/en/PR_Write.
I was confused. So I thought PR_Read/PR_Write was just a normal read/
write.

Finally I dug into the implementation of PR_Read/PR_Write in npsr,
everything was clear.

Thanks again for you kindly help!

On 2月7日, 下午5时38分, Ryan Sleevi <rsle...@chromium.org> wrote: