Add TLS-SRP (RFC 5054) support

Add TLS-SRP (RFC 5054) support
to allow mutual authentication and TLS session establishment using passwords.

Other discussion at:
http://groups.google.com/a/chromium.org/group/chromium-discuss/browse_thread/thread/f4d1fbac7bceebe9#
http://trustedhttp.org/wiki/TLS-SRP_in_Chrome

Includes additions to Chrome net/ and chrome/ as well as 
OpenSSL, NSS, and TLS Lite. It updates URLRequest, HTTP 
transaction, and NSS SSL client socket code in net/ and exposes 
SetTLSLogin and ContinueWithTLSLogin (etc.) methods in URLRequest. The 
UI code presents a login dialog when users browse to TLS-SRP-enabled 
servers and displays the logged-in username in the location bar. It 
also displays the TLS-SRP security information in the page info 
display. Adds httpsv scheme that requires TLS-SRP authentication in a TLS connection.

BUG=
TEST=Linux only for now. net_unittests and base_unittests pass; some unit_tests currently fail. Requires external patches to NSS; see http://trustedhttp.org/wiki/TLS-SRP_in_Chrome for more information.

[sqs, 2011-04-06 23:29:17]

Thanks for offering to take a look at this. There is also an email thread on
higher-level issues with Shabsi Walfish and other Google people and David
Mazieres and me from Stanford. If you want, I can forward that to you.

The chrome/ UI code for creating the username display in the location bar needs
some work--it's far too specific to this one use case. The other UI code (for
the page info box) and the net code is more solid.

[PhistucK, 2011-04-07 07:08:28]

I happened to spot these.

http://codereview.chromium.org/6804032/diff/1/ppapi/c/dev/ppb_opengles_dev.h
File ppapi/c/dev/ppb_opengles_dev.h (right):

http://codereview.chromium.org/6804032/diff/1/ppapi/c/dev/ppb_opengles_dev.h#...
ppapi/c/dev/ppb_opengles_dev.h:1: // Copyright (c) 2011 The Chromium Authors.
All rights reserved.
No need to update copyright lines of untouched files.

http://codereview.chromium.org/6804032/diff/1/ppapi/lib/gl/gles2/gles2.c
File ppapi/lib/gl/gles2/gles2.c (right):

http://codereview.chromium.org/6804032/diff/1/ppapi/lib/gl/gles2/gles2.c#newc...
ppapi/lib/gl/gles2/gles2.c:1: // Copyright (c) 2011 The Chromium Authors. All
rights reserved.
Same here.

http://codereview.chromium.org/6804032/diff/1/webkit/plugins/ppapi/ppb_opengl...
File webkit/plugins/ppapi/ppb_opengles_impl.cc (right):

http://codereview.chromium.org/6804032/diff/1/webkit/plugins/ppapi/ppb_opengl...
webkit/plugins/ppapi/ppb_opengles_impl.cc:1: // Copyright (c) 2011 The Chromium
Authors. All rights reserved.
Same here.

[sqs, 2011-04-07 07:35:15]

On 2011/04/07 07:08:28, PhistucK wrote:
> I happened to spot these.
> ...
> No need to update copyright lines of untouched files.

Fixed those. Thanks!

[agl, 2011-04-07 14:16:05]

First, thank you for the huge amount of work that has clearly gone into this
code. Chromium is a large and very complex codebase and getting this working is
impressive.

I think that TLS-SRP may be useful for a small number of sites, although the
level of support on the team is luke-warm. I can help shepherd, but it may turn
out that am I alone in my support, in which case the changes to Chromium may be
declined.

I'm just saying this now because getting this patch landed will still be a very
significant amount of work I'm afraid.

The changes to TLSLite and NSS are both independently useful and independent of
any other parts of the patch so it would make sense to start there.

The TLSLite changes, if split into their own patch, are pretty much good to go.

I'm not an NSS reviewer, although I've written some code for it. Before I start
looking at the NSS patches I should note that dropping an MPI library into the
SSL code, while expeditious, is not going to fly. Due to the design of NSS, the
changes need to go into the freebl library. This means getting NSS from CVS (*),
making some changes there and some changes in Chromium's libssl.
(LD_LIBRARY_PATH is your friend here.) You can probably set
GYP_DEFINES="use_system_ssl=1" to avoid using Chromium's libssl in the interim.

This does mean that the SRP code may have to be conditional in Chromium's libssl
because we cannot assume that the system libnss is up to date. It also means
that SRP support in Chromium will be dependent on the version of the system
library. However, we ship with freebl on Mac and Windows, so they'll have SRP
support based only the Chromium version.

(*) when working on NSS, I recommend `find -type d -name CVS | xargs rm -Rf`
followed by `git init` for sanity. Although you'll need to patch changes back
into a CVS checkout to get a compatible diff for upstreaming to NSS.

[agl, 2011-04-07 14:56:27]

wtc pointed out that there are entries in the NSS bug tracker for this,
specifically [1]. Comment #15 there suggests a PKCS#11 module for the SRP code.
I know very little about PKCS#11, but Nelson knows a lot about NSS, so it may be
worth investigating. Either way, we would like to avoid another MPI library.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=405155

[sqs_cs.stanford.edu, 2011-04-07 17:54:22]

On Thu, Apr 7, 2011 at 7:56 AM,  <agl@chromium.org> wrote:
> wtc pointed out that there are entries in the NSS bug tracker for this,
> specifically [1]. Comment #15 there suggests a PKCS#11 module for the SRP
> code.
> I know very little about PKCS#11, but Nelson knows a lot about NSS, so it
> may be
> worth investigating. Either way, we would like to avoid another MPI library.

Got it. I'm working on the NSS patch now to address the issues that
were raised in #405155 and get it ready for them to consider again.
And yeah, I'll definitely take the MPI library out of the Chrome
patch.

[sqs_cs.stanford.edu, 2011-04-07 22:02:56]

On Thu, Apr 7, 2011 at 7:16 AM,  <agl@chromium.org> wrote:
> I think that TLS-SRP may be useful for a small number of sites, although the
> level of support on the team is luke-warm. I can help shepherd, but it may
> turn out that am I alone in my support, in which case the changes to Chromium
may
> be declined.
>
> I'm just saying this now because getting this patch landed will still be a
> very significant amount of work I'm afraid.

Thanks for your support, and I understand that there's much more work
to be done with a highly uncertain outcome. For now, we will keep
working on the Chrome patch and at the same time present the case for
TLS-SRP to the people who aren't supportive or who are undecided.
David (cc'd) is working on that front.

> The changes to TLSLite and NSS are both independently useful and independent
> of any other parts of the patch so it would make sense to start there.

Yeah, I've submitted the TLS Lite patch upstream, although it is no
longer being maintained. (I may start helping with maintenance,
actually.) I'm also working on the NSS patch to reopen the process of
getting TLS-SRP into NSS. It will be helpful to point to this Chrome
patch and the Firefox TLS-SRP login UI patch during that process as
evidence that there is demand for TLS-SRP in NSS. (Progress on TLS-SRP
integration overall is accelerating: it's been in GnuTLS for years,
cURL for a few months, and it should be in the next release of
OpenSSL.)

> This does mean that the SRP code may have to be conditional in Chromium's
> libssl
> because we cannot assume that the system libnss is up to date. It also means
> that SRP support in Chromium will be dependent on the version of the system
> library. However, we ship with freebl on Mac and Windows, so they'll have
> SRP
> support based only the Chromium version.

Got it. I'll make it conditional. Would it be possible at some point
for us to use the tryservers for testing?

-Quinn

[sqs, 2011-04-11 01:16:41]

On Thu, Apr 7, 2011 at 7:16 AM,  <mailto:agl@chromium.org> wrote:
> The changes to TLSLite and NSS are both independently useful and independent
> of any other parts of the patch so it would make sense to start there.

FYI, I just revived the NSS TLS-SRP patch and will be trying to push that along.

https://bugzilla.mozilla.org/show_bug.cgi?id=405155#c16

[wtc, 2011-04-20 18:00:37]

sqs: thanks a lot for contributing the patch to Chromium.

I skimmed through the patch.
- Most of the changes are in NSS.
- Chrome's net/http and net/url_request get some modest
  changes.
- The use of the "httpsv" URL scheme for TLS-SRP requires
  changing a lot of files that check for "https".  This is
  unfortunate.
- The new tls_username needs to be passed around.

So the code size increase to Chrome proper seems moderate.
The "httpsv" changes could be difficult to maintain.

I am not familiar with TLS-SRP, so I am not sure if we
should check in this patch.  There are several new efforts
underway in Chrome to improve the security or performance
of SSL.  I am inclined to apply our code size and
maintenance budget to new code that benefits the most users.

http://codereview.chromium.org/6804032/diff/12047/net/third_party/nss/ssl.gyp
File net/third_party/nss/ssl.gyp (right):

http://codereview.chromium.org/6804032/diff/12047/net/third_party/nss/ssl.gyp...
net/third_party/nss/ssl.gyp:127: '-lnssdbm3', # TODO(sqs): still needed?
I believe this change is wrong.  libnssdbm3 is dynamically
loaded with a dlopen() call (or equivalent) if the old Berkeley
DB 1.85 should be used.  Chrome configures NSS to use sqlite3.

http://codereview.chromium.org/6804032/diff/12047/net/third_party/nss/ssl/ssl...
File net/third_party/nss/ssl/ssl.def (right):

http://codereview.chromium.org/6804032/diff/12047/net/third_party/nss/ssl/ssl...
net/third_party/nss/ssl/ssl.def:142: SSL_GetSRPParamsHook;
These should be added to the NSS_3.13 section at the end of
this file.  NSS 3.11.8 is already released, so its list of
exported functions is a done deal.  NSS 3.13 is the upcoming
release from the NSS trunk.

[sqs, 2011-04-20 19:11:13]

Thanks for looking this over, wtc. I'll fix the NSS things, and...

On 2011/04/20 18:00:37, wtc wrote:
> - The use of the "httpsv" URL scheme for TLS-SRP requires
>   changing a lot of files that check for "https".  This is
>   unfortunate.
>
> The "httpsv" changes could be difficult to maintain.

I am working on a patch without "httpsv" that I'll upload soon. This should
significantly decrease the code size and complexity.

[wtc, 2011-04-20 23:32:32]

sqs: just curious: where does the "httpsv" scheme come from?  I didn't
find it in RFC 5054, and my Google and Bing searches didn't turn up
anything.

[sqs, 2011-04-20 23:53:10]

On 2011/04/20 23:32:32, wtc wrote:
> sqs: just curious: where does the "httpsv" scheme come from?  I didn't
> find it in RFC 5054, and my Google and Bing searches didn't turn up
> anything.

Totally made up by someone who had previously implemented PAKE login for
Firefox. I took it from that.

The idea was to let users require TLS-SRP for certain URLs (by using httpsv) but
not others. E.g., they might want to require TLS-SRP for their blog's admin
interface, so they wouldn't be fooled by an attacker who got a CA to produce a
bad certificate and who then hijacked their server to perform SSL with that
cert. Likewise for a server wanting to require PAKE.

I decided, however, that this would be an unwieldy and overly specific solution
to a larger problem that STS (and, e.g., DANE) already addresses.

Having a separate scheme does make it easier to allow logging in and logging out
(log in = redirect to httpsv, log out = redirect to https) through content-area
links (as opposed to a log out button in browser chrome), but there are other
ways to do this.

[heri16, 2014-07-31 16:17:39]

On 2011/04/20 23:53:10, sqs wrote:
> On 2011/04/20 23:32:32, wtc wrote:
> > sqs: just curious: where does the "httpsv" scheme come from?  I didn't
> > find it in RFC 5054, and my Google and Bing searches didn't turn up
> > anything.
> 
> Totally made up by someone who had previously implemented PAKE login for
> Firefox. I took it from that.
> 
> The idea was to let users require TLS-SRP for certain URLs (by using httpsv)
but
> not others. E.g., they might want to require TLS-SRP for their blog's admin
> interface, so they wouldn't be fooled by an attacker who got a CA to produce a
> bad certificate and who then hijacked their server to perform SSL with that
> cert. Likewise for a server wanting to require PAKE.
> 
> I decided, however, that this would be an unwieldy and overly specific
solution
> to a larger problem that STS (and, e.g., DANE) already addresses.
> 
> Having a separate scheme does make it easier to allow logging in and logging
out
> (log in = redirect to httpsv, log out = redirect to https) through
content-area
> links (as opposed to a log out button in browser chrome), but there are other
> ways to do this.

Hi Sqs,

I was wondering what happened to the patch that you are working on for TLS-SRP? 
It seems that Certificate Authorities cannot be trusted anymore these days after
the Snowden revelations.
According to the EFF SSL Observatory, 2000 different entities can sign
certificates for any domain on the internet, including yahoo.com or
chromium.org. 
TLS-SRP is the most elegant solution for many use cases.

Thanks.