[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shim6 proxies
Iljitsch van Beijnum wrote:
Unless I'm mistaken, if you go to an HTTPS website, what happens is that
your browser gets a certificate from the server that proves that the
holder of the certificate has a certain identity, such as
www.example.com. The browser checks whether the server has the private
key for the certificate by sending it a challenge and checks if the
identity in question matches the URL, which, I imagine, requires some
DNS lookups.
shim6 security could work much the same way by tying a certificate to a
ULID, either with or without the intermediate step of an FQDN. Such a
certificate allows a host to prove that it holds a certain identity,
irrespective of the address it's actually using. Once you know who
you're talking with you can mostly believe them when they say what their
locators are, you just need to send a packet to those locators to make
sure the same host is present there to avoid the possibility of someone
dumping shim6 traffic on an unrelated third party.
As for the PKI, yes, you need some kind of infrastructure, but it's
already there so I don't see the problem, especially for enterprises and
content hosters. Most home users don't have a certificate, but they can
still use HBA. (Note that in the above scenario only one side (usually
the server) needs a certificate.)
I can see this working, but it can't securely recover a context after a
failure failure! This is because there is no trusted relationship
between the certificate for the server and the alternate locators of the
server. (And I have only thought about end-to-end use of this - not
proxy use - so I don't know if that would add some further complications.)
The host (which doesn't have a cert) uses HBA. Looks up www.example.com
and gets some IP addresses. The shim6 layer on the host is told the FQDN
for the peer.
During the shim6 context establishment TLS is used, which verifies the
server's cert. If the server needs to use a different locator it can use
TLS to tell the client the new locator; the shim6 layer needs to verify
that the same cert is used for the locator update as was used for the
context establishment.
But that happens if the client looses the context and the server needs
to send it some data? One would have to fall back on essentially return
routability, since the client's shim doesn't remember the FQDN of the
server any more (perhaps the application remembers the FQDN but that
doesn't help unless we redo all the socket APIs from scratch).
The worst case is when the client has lost the context and the server
needs to contact the client but using a locator that is different than
its ULID; in this case even return routability can't be used.
Thus it would allow the server to say "my FQDN is www.foo.com and this
is my cert, and even though I'm using locator X, I also have ULID=Y -
trust me".
You could argue that the bulk of these problems occur when the "server"
needs to contact the "client" and that this case isn't important. But if
we'd want to add this, I think "server" is really "host that has a cert"
thus we'd want this security scheme to work independently of the
application layer roles (server vs. client) of the host that has the
certificate.
So I don't see how the certificate helps, unless there is a global PKI
which can assertively state the IP addresses of the holder of the
certificate (and have this somehow be updated when the site/host
renumbers). Without this, all we seem to get is something analogous to
anonymous diffie-hellman, and that doesn't help prevent time-shifted
redirection attacks.
I think one can try to do things using DNS forward+reverse lookups for
verification of relationships between ULIDs and locators. The old NOID
draft explored this space. But my personal conclusion was that such an
approach would be expensive, since to be reasonably secure, the hosts
would have to do forward+reverse lookup (or reverse+forward) even before
establishing the shim context. There was also the issue that NOID
assumed that all communicating parties had correct forward+reverse DNS
entries.
But it might make sense to look at the possibility of using DNS
verification for one end and HBA for the other.
Erik