[clug] OT: Protesting the proposed clean feed?

Nathan Rickerby rickerby at gmail.com
Thu Oct 23 11:48:05 GMT 2008

On Thu, Oct 23, 2008 at 09:38:07PM +1100, Peter Barker wrote:
> On Thu, 23 Oct 2008, Nathan Rickerby wrote:
>> Without a method for seeing the certificate the ISP gets when making the
>> second https connection, how can you verify they are connecting to the
>> true intended destination.  The connection could be man-in-the-middled
>> again between the ISP and your bank.
> I'd have thought that connection would be secure; the ISP can verify  
> certificates as well as you can :)  And since they're doing a MitM attack 
> against you, they can even present you with a bad-certificate message  
> (with advertising).

Say I've had a face to face meeting with someone I want to do business
with.  Neither of us trust the standard 'trusted' CAs on the Internet,
so we haven't had our certs signed by one.  Now we've met and somehow
established trust we've gone one better than using a third party.  We handed
each other business cards with the key fingerprints for our https servers.

As things are now I can connect to their server, check the key fingerprint
matches the one on the card and be confident that tls has served us well.

But what if the ISP was to MitM my connection.  How can they verify
the certificate?  It's not signed by a CA they trust, I can do a much
better job of verifying the certificate than they can.  How do I control
who the ISP trusts?

The ISP can generate a certificate with the correct CN, have it signed
on the fly by a CA that browsers have been coerced into trusting, there
will be no error message but the keys still won't match.

You can imagine solutions where the ISP presents an advertisement littered
page saying here are the credentials for the server I just connected to
for you, click here if they're okay or disconnect.  It's awful, but maybe
it would be okay... for a web browser.  What about my tls vpn application
that's expecting to start some other protocol over the tls tunnel but
now the ISP is trying to talk http to it.  That's just not going to work
well at all.

Another solution might be that you can configure via some other web based
system what CAs and certificates you trust for your internet connection.
Or we could invent a whole new protocol for projecting who you trust
to your ISP (maybe that already exists).  This is all a very bad idea
and it's trying to undo what this stuff was fundamentally designed to
do.  You always wind up having to trust the security of your ISP and
that they'll do the right thing.


More information about the linux mailing list