916947 - Allow NSS to connect through a SOCKS5 proxy

Status: NEW

(NSS :: Libraries, enhancement, P5)

Description

[Kai Engert (:KaiE:)]

Attachment: socks5.c

I'm working on a project that requires to route TLS connections through a SOCKS5 proxy.

Mozilla's necko code already supports it, but that code is in C++.

I ported the SOCKS5 subset of that code to plain C, to allow for integration into NSS, see the attachment.

I propose to add this code to NSS. Alternatively, if you think this code is sufficiently generic to rather be added to NSPR, that's fine, too.

I'm interested in your feedback: Add to NSPR or add to NSS?

Comment 1

[Ryan Sleevi]

Comment on attachment 805516 [details]
socks5.c

Can you describe the use case for this?

I'd much rather that either
a) NSS only uses NSPR primitives
b [MUCH more preferred]) NSS delegates to an embedder to handle connection management/establishment. Possibly a 'default' implementation supplied by NSPR, but would much rather prefer to be able to override this at the app layer.

Comment 2

[Kai Engert (:KaiE:)]

> Can you describe the use case for this?

The use case is the idea that I describe at http://detector.io

> I'd much rather that either
> a) NSS only uses NSPR primitives

This code doesn't require anything besides NSPR code (I believe). I've just seen it includes secport.h, but I guess that's only for allocation functions.


> b [MUCH more preferred]) NSS delegates to an embedder to handle connection
> management/establishment. Possibly a 'default' implementation supplied by
> NSPR, but would much rather prefer to be able to override this at the app
> layer.

The intention is to be able to use this code, even if the application hasn't registered anything for delegation of connections.

The code that I have in mind wouldn't want to use the application's proxy, because that's the "direct route". Instead I want to use multiple special proxies to test multiple routes for global certificate use consistency checking. Those proxies would have to be configured separately anyway, and details for that need to be discussed separately at a future time.

Comment 3

[Ryan Sleevi]

(In reply to Kai Engert (:kaie) from comment #2)
> > Can you describe the use case for this?
> 
> The use case is the idea that I describe at http://detector.io
> 
> > I'd much rather that either
> > a) NSS only uses NSPR primitives
> 
> This code doesn't require anything besides NSPR code (I believe). I've just
> seen it includes secport.h, but I guess that's only for allocation functions.
> 
> 
> > b [MUCH more preferred]) NSS delegates to an embedder to handle connection
> > management/establishment. Possibly a 'default' implementation supplied by
> > NSPR, but would much rather prefer to be able to override this at the app
> > layer.
> 
> The intention is to be able to use this code, even if the application hasn't
> registered anything for delegation of connections.
> 
> The code that I have in mind wouldn't want to use the application's proxy,
> because that's the "direct route". Instead I want to use multiple special
> proxies to test multiple routes for global certificate use consistency
> checking. Those proxies would have to be configured separately anyway, and
> details for that need to be discussed separately at a future time.

This is something we'd want to compile out for Chromium, and I suspect Brian would prefer the same for Firefox.

In Chromium's use of NSS, NSS should never perform any IO. It should always be mediated through Chromium's network stack.

Historically, crypto libraries that intentionally attempt to ignore the application's settings (eg: CryptoAPI on Win, ocspd on OS X) provided the greatest difficulty for usability and privacy, despite claims otherwise.

While useful, I would prefer to not see this in NSS, and instead be integrated at an application layer.

Comment 4

[Robert Relyea]

So not all applications that use NSS have a network layer (libldap, for instance). Certainly applications like Chrome and Firefox *do* have network layers, and NSS will preferentially use them. The question is does the fallback code (which we already have) need to support SOCKS proxying. Up until now I think the answer has been no. 

I think if we determine that we need it, we should probably add the capability to NSPR itself. I think we need to be careful, however, of adding to many features to the NSPR sockets. We certainly don't want to replicate all the functionality of a browser networking layer.

bob