openssl or nss?

[Wayne]

Hi,

I noticed the third_party/openssl directory. I thought Chrome uses nss
library. Does it switch to use openssl now?

I am new to the dev. I have just downloaded the code and built it on
ubuntu earlier today. I have not browsed through the code yet.
Is there any design doc on https related handling? (or where is a good
starting point in reading through the SSL(https) related code?)

Thanks,
W. Shao

[Jonathan Dixon]

Welcome to chromium!

On 21 December 2010 10:30, Wayne <wsh...@gmail.com> wrote:

Hi,

I noticed the third_party/openssl directory. I thought Chrome uses nss
library. Does it switch to use openssl now?

Chrome does indeed use NSS, as you thought. The openssl code is experimental, as as per the comment buried in common.gypi it is not as complete as NSS in its feature set.

 

I am new to the dev. I have just downloaded the code and built it on
ubuntu earlier today. I have not browsed through the code yet.
Is there any design doc on https related handling? (or where is a good
starting point in reading through the SSL(https) related code?)

http://dev.chromium.org/developers/design-documents/network-stack is a good starting point, and see in particular the SSL sub-pages link on the footer of that page.

 

Thanks,
W. Shao

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[Wayne]

Thanks!

On Dec 21, 2:38 am, Jonathan Dixon <j...@chromium.org> wrote:
> Welcome to chromium!
>

> On 21 December 2010 10:30, Wayne <wsha...@gmail.com> wrote:
>
> > Hi,
>
> > I noticed the third_party/openssl directory. I thought Chrome uses nss
> > library. Does it switch to use openssl now?
>
> > Chrome does indeed use NSS, as you thought. The openssl code is
>
> experimental, as as per the comment buried in common.gypi it is not as
> complete as NSS in its feature set.
>

oh, experimental!
Does it mean that openssl is used in my Debug build? Or is there a
switch somewhere?
I need to experiment some ssl related handling. I want to make sure I
am changing the right library before I start.

> > I am new to the dev. I have just downloaded the code and built it on
> > ubuntu earlier today. I have not browsed through the code yet.
> > Is there any design doc on https related handling? (or where is a good
> > starting point in reading through the SSL(https) related code?)
>

> http://dev.chromium.org/developers/design-documents/network-stackis a good

> starting point, and see in particular the SSL sub-pages link on the footer
> of that page.
>

> <http://dev.chromium.org/developers/design-documents/network-stack>
>
>
>
>
>
>
>
> > Thanks,
> > W. Shao
>
> > --
> > Chromium Developers mailing list: chromium-...@chromium.org

[Jonathan Dixon]

On 21 December 2010 10:45, Wayne <wsh...@gmail.com> wrote:

Thanks!

On Dec 21, 2:38 am, Jonathan Dixon <j...@chromium.org> wrote:
> Welcome to chromium!
>

> On 21 December 2010 10:30, Wayne <wsha...@gmail.com> wrote:
>
> > Hi,
>
> > I noticed the third_party/openssl directory. I thought Chrome uses nss
> > library. Does it switch to use openssl now?
>
> > Chrome does indeed use NSS, as you thought. The openssl code is
>
> experimental, as as per the comment buried in common.gypi it is not as
> complete as NSS in its feature set.
>

oh, experimental!
Does it mean that openssl is used in my Debug build? Or is there a
switch somewhere?
I need to experiment some ssl related handling. I want to make sure I
am changing the right library before I start.

All standard configurations use NSS, you have to go out of your way to use openssl. (e.g. export GYP_DEFINES=use_openssl=1)

Only one of the nss or openssl version of a file gets built, so to double check, you can e.g. introduce a compile error into the file you're editing and check the build fails as expected.

[Кирилл Романовский]

Are there any changes in the OpenSSL status? I haven't found any newer posts, and common.gypi has a mention that OpenSSL support is still under development.

[Torne (Richard Coles)]

OpenSSL is only used when building on Android; it is semifunctional on Linux but is not expected to be suitable for users.

--
--
Chromium Developers mailing list: chromi...@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Raphael Kubo da Costa]

"Torne (Richard Coles)" <to...@chromium.org> writes:

> OpenSSL is only used when building on Android; it is semifunctional on
> Linux but is not expected to be suitable for users.

Jonathan and others, could you expand on this?

From a content API perspective, how secure or tested is the OpenSSL
support? If one chooses to use OpenSSL on a platform other than Android,
is it as secure as using NSS? Is there something to watch out for? How
much of the code that makes the SSL connections secure is in
Android-specific blocks?

[Jonathan Dixon]

The main android specific bit is dealing with system  cert store for server  authentication. As such the Linux version of the same should be considered insecure / unimplemented until work is done to integrate with a given distro cert store and verify the integrated product.

There's a bug somewhere recording other missing corner cases I can dig out if you're interested, although at this point my personal guess is long term the project would only reduce not increase openssl usage.
(The original driver was binary size saving, but devices have much larger drives than even two years ago so a couple more years this difference could be immaterial)

[David Turner]

On Thu, Oct 10, 2013 at 4:19 PM, Raphael Kubo da Costa <raphael.ku...@intel.com> wrote:

"Torne (Richard Coles)" <to...@chromium.org> writes:

> OpenSSL is only used when building on Android; it is semifunctional on
> Linux but is not expected to be suitable for users.

Jonathan and others, could you expand on this?

From a content API perspective, how secure or tested is the OpenSSL
support?

I would say that, from a content API perspective, consider it _untested_ and _incomplete_ for any platform other than Android.

The OpenSSL-specific code piggybacks to Android system APIs (to retrieve client certificates from the secure credential storage,

to perform signing and to verify certificate chains). I don't think there is any support to do the same for any other platform. While it should
be possible to add the missing plumbing, this might be significant work.

 

Installation and selection of client certificates also requires special handling at the chrome/ layer, but this doesn't affect content/ directly,

and is more related to Android than OpenSSL. Though one would need to check carefully first :-)

 

If one chooses to use OpenSSL on a platform other than Android,
is it as secure as using NSS? Is there something to watch out for? How
much of the code that makes the SSL connections secure is in
Android-specific blocks?

 

- David

[David Turner]

On Thu, Oct 10, 2013 at 4:34 PM, Jonathan Dixon <jo...@google.com> wrote:

The main android specific bit is dealing with system  cert store for server  authentication. As such the Linux version of the same should be considered insecure / unimplemented until work is done to integrate with a given distro cert store and verify the integrated product.

There's a bug somewhere recording other missing corner cases I can dig out if you're interested, although at this point my personal guess is long term the project would only reduce not increase openssl usage.
(The original driver was binary size saving, but devices have much larger drives than even two years ago so a couple more years this difference could be immaterial)

Note that, in order to work-around platform flaws in Android < 4.2, we sometimes have to, hum......, creatively process OpenSSL objects provided by the system :-/ Any plan to remove OpenSSL from the Android build would have to take this into account.

[Chris Bentzel]

On Thu, Oct 10, 2013 at 11:13 AM, David Turner <di...@chromium.org> wrote:
>
>
>
> On Thu, Oct 10, 2013 at 4:34 PM, Jonathan Dixon <jo...@google.com> wrote:
>>
>> The main android specific bit is dealing with system cert store for
>> server authentication. As such the Linux version of the same should be
>> considered insecure / unimplemented until work is done to integrate with a
>> given distro cert store and verify the integrated product.
>>
>> There's a bug somewhere recording other missing corner cases I can dig out
>> if you're interested, although at this point my personal guess is long term
>> the project would only reduce not increase openssl usage.
>> (The original driver was binary size saving, but devices have much larger
>> drives than even two years ago so a couple more years this difference could
>> be immaterial)
>>
> Note that, in order to work-around platform flaws in Android < 4.2, we
> sometimes have to, hum......, creatively process OpenSSL objects provided by
> the system :-/ Any plan to remove OpenSSL from the Android build would have
> to take this into account.

Good to know. I've been wondering whether we should move to NSS on
Android since we aren't using the Android platform-provided OpenSSL
library anyway. This would hopefully simplify development long-term
anyway.

wtc+sleevi would be in a much better position than me to make the call though.

[David Turner]

On Sun, Oct 13, 2013 at 3:44 PM, Chris Bentzel <cben...@chromium.org> wrote:

> Note that, in order to work-around platform flaws in Android < 4.2, we
> sometimes have to, hum......, creatively process OpenSSL objects provided by
> the system :-/ Any plan to remove OpenSSL from the Android build would have
> to take this into account.

Good to know. I've been wondering whether we should move to NSS on
Android since we aren't using the Android platform-provided OpenSSL
library anyway. This would hopefully simplify development long-term
anyway.

wtc+sleevi would be in a much better position than me to make the call though.

I think the most important fact here is that on Android, Chrome uses the system APIs to perform certificate verification, signing and to access the credential store.

I don't know much about NSS, but I would be shocked, shocked, if implementing these wouldn't require some work :-) Just my 2 cents so we can plan this appropriately.