firewalls and TLS and DNSsec was: Web Object Encryption and Signing (WOES) at IETF

[fixed some major gobbledegook in (1b)(2a) below]

On 18 Feb 2011, at 21:16, Peter Williams wrote:

> Now you've read wikipedia about winsock and sockets, go and see how one plugsin layer protocols that modify the semantics of ssl ( on a 400$ consumer pc, not a university grade unix workstation costing $2000).
> 
> If you want, do read the ssl patent, since it's all about secure sockets (not browsers). This included how to deliver https to browsers with no tcp capability ( mostly novell LANs ). This is all about leveraging the socket, transport bridges, and leveraging the extensibility model of ssl itself (that tls implementations must support).

Yes, even more useful is how to do tcp without cables. It's called TCP/IP over pigeans and there is an
RFC for it. According to this article they can achieve 2.27 Mbps

http://ropata.wordpress.com/2005/06/18/tcpip-traditional-carrier-pigeon-internet-protocol/

which is really useful if your dictator decides to shut down the telephone system. 
So yes, these are protocols, and very flexible ones too as far as implementation goes.

> Another story from rsa conference is now relevant. It's at layer 7, not 4 though.
> 
> Sonicwall make firewalls for ISPs and corporate LANs, and cloud tenants (new market, thanks to the likes of openid, oauth etc).
> 
> Their https interceptor tied to the classical web proxy not only spoofs the real server name, but bridges client auth too.

Presumably this only works if the company has put a fake Root CA certificate in the employees browsers, in the Trusted Authorities (TA) list. Otherwise the browser would on connecting to the company's firewall receive from it a certificate claiming to be by say amazon.com but not signed by one of the browsers official CAs. The browser would then throw an error message.

If a "fake" root CA has been placed in the employee's browser  then of course the proxy/firewall can pretend to be anyone since it has the corresponding private key and the browser will accept all certificates signed by it. 

> One asserts the webid to the "inspector" node, and it makes a new client auth handshake with the real server (unseen by user).

Now everything from here on depends on whether 

(1) the firewall/inspector 
    (a) has your certificate's private key 
    (b) does not have your private key 
(2) the WebID you send in your certificate is 
    (a) your personal WebID 
    (b) the company's WebID

> It attaches your cert to it's chain, dynamically signing it (wheter self signed or third party signed). 
> Obviously, it can change the webid field URL, pointing at it's own (cached rdf) endpoints (where it mints an rdf stream with an unsigned public key triple within, value identical to the client cert in the "post inspected" handshake exchanged with the real server.

So let us look at the four cases above

(1a)(2a) the firewall has your private key for your personal WebID
    -> there it will be able to make sites you connect to think you are connecting directly to them as your private persona. 
 But the firewall could do that while you are away, so you really need to trust your company.  Somehow this does not seem like the right thing to do - don't do private business on your company computer takes a whole new meaning here.

(1a)(2b) the firewall has your private key for your company WebID
    -> as above (1a)(2a), but at least this feels like it is defendable
       But really there is not need for your company to have your certificate private key because it can easily create a new certificate and publish that public key on the company's public site - see (1b)(2b)

(1b)(2a) The firewall does not have your private key for your personal WebID
     -> So here when in the client auth procedure the firewall sends you a token - tied to your session  -  your browser can sign it with your private key and prove to the firewall that you are tied to the certificate sent earlier correctly. But the firewall itself cannot prove that same thing to the site you are trying to login to, since it does not know the private key of your certificate. 
 2 options:
  - could the firewall create a new certificate with your WebID? If it did that certificate would have to have a new public key, and so the second part of the WebID authentication step - the one where amazon.com tries to authenticate you by GETing your WebID - would not work, since your company does not have access to your personal profile. 
  - could the firewall create a new certificate with a company WebID? yes, it could. But then you would just appear to the site you were trying to log into as a different persona. Essentially it would be a case of (1b)(2b) described below.
      There is nothing the firewall proxy can do here. Luckily. But it also means that you cannot do your private banking in such a company, or deal with personal matters while at work. 

 (1b)(2b) The firewall does not have your private key for your company WebID
    -> here as opposed to (1b)(2a) above, the company can create a new certificate and publish the public key to your profile page which it controls. When you connect to the firewall using your private key, your company connects with its certificate to the service you are trying to link to using its private key and its certificate. You can thus do business as an employee of your company behind their firewall.

So I discussed this on this list not so long ago , not quite in this length perhaps in Issue-28
"How does the WebID protocol (foaf+ssl) interact with TLS proxies" 

      http://www.w3.org/2005/Incubator/webid/track/issues/28

There was also an interesting discussion on the Dane list this week, which has a charter that is so simple and so close to what WebID is doing. Instead of authenticating WebIDs they authenticate services (host:port) pairs by placing the public key of what could be self signed server certificates in DNS. 

  http://datatracker.ietf.org/wg/dane/charter/

This would allow future browsers to not show warning messages for sites that have https end points backed by self signed certificates. As John Gilmore founder of the EFF pointed out this would be really useful given that there are 3 times more servers with self signed certs out there than servers with CA signed certs. 

http://www.ietf.org/mail-archive/web/keyassure/current/msg01813.html

That thread then turned into a discussion about how one could make it work with company firewalls. Because as we discussed above the current firewall solutions can only work because the firewall can play the CA game by placing a fake CA in the users browsers in the Trusted Authorities (TA) collection.  It turns out that in that world, browsers would have to fake the DNSsec hierarchy too.

  http://www.ietf.org/mail-archive/web/keyassure/current/msg01837.html

complicated, but that's what one has to do when one wants to control everyone: pay out.

> Of course, the inspectors cert chain may terminate at a self signed root or such as an ev root, which is distributed by most server vendors and automatically trusted.
> 
> Now, is this a use case, a threat, or what? It's obviously webid related.

I don't think they are threats. When you are part of a company, you are speaking for that company. In a sense you are a cell of that larger body. If it wants you to speak with their identity that is their prerogative. Yours is not to work for such a company. It will be interesting how more distributed companies can grow as a network of independent cells, and if they can be more flexible and dynamic by doing that.

	Henry Story

Social Web Architect
http://bblfish.net/

Received on Friday, 18 February 2011 23:47:07 UTC