You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2005/11/05 12:17:52 UTC
pgp trust for https?
We have grown accustomed to two separate trust mechanisms
on the 'net; server certs signed by some authority, or the PGP
web of trust.
I would like to be able to use PGP trust over the web. That would
mean (something like) installing a certificate on the server, and
signing it with my PGP key. My browser, having access to and
trust in, my public key, will then trust the server. No need for
any dealings with verispam.
Is there any technical reason this shouldn't happen?
--
Nick Kew
Re: pgp trust for https?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Nov 08, 2005 at 12:02:03PM +0000, Brian Candler wrote:
> The attacker doesn't have your private key, so they would create their own
> key pair. As a result, the connecting client would see a *different* key
> than the one they would see if they connect to your server directly. The
> problem is, they have no way of telling which key is the one which belongs
> to you, and which one is the one which belongs to the attacker.
Like many here; I've met Nick, and he gave me his key details in person.
That makes me plenty insulated from a man in the middle attack. That's
how PGP works.
> If the client knows you personally, they can phone you up and ask for you to
> read the key fingerprint over the phone, or fax it to them. That doesn't
> scale very well.
No, but it is a lot closer to an actual trust relationship. Trust
doesn't scale. I mean, how many people do you trust?
> So generally the client has to rely on a third-party to sign the key;
That's the part a lot of us don't consider trustworthy.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: pgp trust for https?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Peter J. Cranstone wrote:
>
> But seriously though, Apache now has 70% of the Internet web servers running
> it's software. The single most important thing on IT minds is web services
> followed by "security".
Yup. Apache takes a wee bit of pride that it comes up so infrequently on
bugtraq, and hides in shame when it does, meekly offering up a patch (usually
quickly, sometimes drawn out when the underlying mechanics are in the way.)
Most importantly - users can find out exactly what the buggy code was, and
if the fix actually solves it (or bring up another report if we haven't.)
This, as opposed to the process of exploit development, proof of concept,
and then lack of verification of fixes to 'the other webserver'. So you
are probably right...
> Apache needs to think about what it's going to do to make the server more
> secure. If you don't someone is going to come in and steal the limelight. I
> doubt it will be Microsoft but who knows maybe Google does it.
But Longhorn and managed code is the final solution, no? <LOL>
Most likely, the viable solution comes out of an unexpected corner of the
IT space. At least, that's where most
> Security is a big deal - and it's not off-topic for any forum these days
> unless of course you're tired of being the lead dog on the Internet.
The httpd's security isn't off topic, I'll agree. Debating or promoting
different ring and kernel architectures is off topic, though, when you
aren't applying them to an operating system that httpd can run on. (Of
course anyone is welcome to take the httpd code off to their own project
to develop embedded httpd in a truly security environment.)
Apache projects are designed around standards, and unencumbered ones at
that. We leverage platforms, so sure, once there is a solid OS to support,
then it's something that is worth discussing IN THE CONTEXT of httpd. But
without an actual operating system that's worth its weight in security,
that httpd can target, the thread's Potlemaic are cute but irrelevant.
So rather than spin off-topic threads, where's the discussion of taking
something that exists, such as se-linux, and actually leveraging security
features of more evolved security architectures? That's when things come
back on-topic here.
Bill
RE: pgp trust for https?
Posted by "Peter J. Cranstone" <cr...@comcast.net>.
Bill,
You're no fun ;-)
But seriously though, Apache now has 70% of the Internet web servers running
it's software. The single most important thing on IT minds is web services
followed by "security".
Apache needs to think about what it's going to do to make the server more
secure. If you don't someone is going to come in and steal the limelight. I
doubt it will be Microsoft but who knows maybe Google does it.
Security is a big deal - and it's not off-topic for any forum these days
unless of course you're tired of being the lead dog on the Internet.
Reminds me of the good old days and the debate around compressing data from
a web server. LOL.
Peter
cranstone1@comcast.net
-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
Sent: Wednesday, November 09, 2005 1:43 PM
To: dev@httpd.apache.org
Subject: Re: pgp trust for https?
Folks, somehow this thread diverged from HTTP/1.1 PGP based TLS mechanisms
into a fun-with-hardware-trust thread.
Please take this discussion to an appropriate security-wonk debating
club forum, such as vuln-dev or bugtraq, as it's all entirely off topic
on this forum.
Yours,
Bill
Re: pgp trust for https?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Folks, somehow this thread diverged from HTTP/1.1 PGP based TLS mechanisms
into a fun-with-hardware-trust thread.
Please take this discussion to an appropriate security-wonk debating
club forum, such as vuln-dev or bugtraq, as it's all entirely off topic
on this forum.
Yours,
Bill
RE: pgp trust for https?
Posted by "Peter J. Cranstone" <cr...@comcast.net>.
Follow up. For those of you who are interested in reading more about how
Itanium supports a secure platform you can read all about it at the US
patent office number: US 2002/0194389 A1
Here's a snip from the abstract..
The combined-hardware-and-software secure-platform interface employs a
hardware platform that provides at least four privilege levels,
non-privileged instructions, non-privileged registers, privileged
instructions, privileged registers, and firmware interfaces. The
combined-hardware-and-software secure-platform interface conceals all
privileged instructions,
privileged registers, and firmware interfaces and privileged registers from
direct access by operating systems and custom control programs, providing to
the operating systems and custom control programs the non-privileged
instructions and non-privileged registers provided by the hardware platform
as well as a set of callable software services. The callable services
provide a set of secure-platform management services for operational control
of hardware resources that neither exposes privileged instructions,
privileged registers, nor firmware interfaces of the hardware nor simulates
privileged instructions and privileged registers. The callable services also
provide a set of security-management services that employ internally
generated secret data, each compartmentalized security-management service
managing internal secret data without exposing the internal secret data to
computational entities other than the security-management service itself.
To solve the security problems you (us, whatever) will have to use a
combination hardware and software architecture. Can't be done in software
alone and it all has to start with Root Trust. If you don't have that then
you have something "else".
Cheers.
Peter
cranstone1@comcast.net
-----Original Message-----
From: Peter J. Cranstone [mailto:cranstone1@comcast.net]
Sent: Wednesday, November 09, 2005 1:12 PM
To: dev@httpd.apache.org
Subject: RE: pgp trust for https?
No problem - Itanium has the architecture you need. You can isolate all the
physical memory into compartments controlled by a protection key. Each
compartment has the ability to individually control read, write and execute
privileges.
Peter
cranstone1@comcast.net
-----Original Message-----
From: Paul A Houle [mailto:ph18@cornell.edu]
Sent: Wednesday, November 09, 2005 1:07 PM
To: dev@httpd.apache.org
Subject: Re: pgp trust for https?
Peter J. Cranstone wrote:
>Currently Windows, Linux and Unix only use two levels of privilege - Ring 3
>and Ring 0. Everybody and there uncle's code want to run at Ring 0. Another
>really bad idea, as once I introduce a network/video/keyboard/whatever
>driver at that level I can execute malicious code. From there I can control
>the machine.
>
>
>
You'd need a new hardware architecture for ring 1 drivers to be
worth it. The trouble is that drivers can initiate DMA operations
against physical memory. Unless you devise some system where the OS can
veto DMA operations, protection in the CPU is worthless.
RE: pgp trust for https?
Posted by "Peter J. Cranstone" <cr...@comcast.net>.
No problem - Itanium has the architecture you need. You can isolate all the
physical memory into compartments controlled by a protection key. Each
compartment has the ability to individually control read, write and execute
privileges.
Peter
cranstone1@comcast.net
-----Original Message-----
From: Paul A Houle [mailto:ph18@cornell.edu]
Sent: Wednesday, November 09, 2005 1:07 PM
To: dev@httpd.apache.org
Subject: Re: pgp trust for https?
Peter J. Cranstone wrote:
>Currently Windows, Linux and Unix only use two levels of privilege - Ring 3
>and Ring 0. Everybody and there uncle's code want to run at Ring 0. Another
>really bad idea, as once I introduce a network/video/keyboard/whatever
>driver at that level I can execute malicious code. From there I can control
>the machine.
>
>
>
You'd need a new hardware architecture for ring 1 drivers to be
worth it. The trouble is that drivers can initiate DMA operations
against physical memory. Unless you devise some system where the OS can
veto DMA operations, protection in the CPU is worthless.
Re: pgp trust for https?
Posted by Paul A Houle <ph...@cornell.edu>.
Peter J. Cranstone wrote:
>Currently Windows, Linux and Unix only use two levels of privilege - Ring 3
>and Ring 0. Everybody and there uncle's code want to run at Ring 0. Another
>really bad idea, as once I introduce a network/video/keyboard/whatever
>driver at that level I can execute malicious code. From there I can control
>the machine.
>
>
>
You'd need a new hardware architecture for ring 1 drivers to be
worth it. The trouble is that drivers can initiate DMA operations
against physical memory. Unless you devise some system where the OS can
veto DMA operations, protection in the CPU is worthless.
RE: pgp trust for https?
Posted by "Peter J. Cranstone" <cr...@comcast.net>.
Something else you all need to consider which currently no one is talking
about. Root trust and chain of trust from the PC - through the OS - to the
application and on to the customer (client)
The issue is simple - how do I know I can trust the machine let alone the
applications running on the machine? The current answer is a TPM chip. Sorry
that's not good enough. TPM allows you to verify that the boot up sequence
hasn't been tampered with, after that you need to ensure that you can build
a chain of trust through the firmware and then the operating system and
finally to the application.
Currently Windows, Linux and Unix only use two levels of privilege - Ring 3
and Ring 0. Everybody and there uncle's code want to run at Ring 0. Another
really bad idea, as once I introduce a network/video/keyboard/whatever
driver at that level I can execute malicious code. From there I can control
the machine.
The web of trust starts much lower in the stack than people are currently
talking about.
What you've outlined below is the following:
Client <----------------> attacker <--------------> Server
Substitute the "attacker" for a legitimate "use" i.e. SSL proxy acceleration
via compression. The man in the middle is now a legitimate user. The benefit
is faster downloads to the customer and conservation of bandwidth. Many
people currently use mod_gzip this way. Works like a champ.
Now of course there's the announcement on News.com today that Blue Coat is
selling a box that sits in the "attacker" spot and decrypts the traffic and
scans it to ensure no spyware etc.
Foiled again. If you want a web of trust start at the machine and extend it
to the operating system and applications via a chain of trust and finally to
the clients desktop. Anything else is simply a band aid which can be used
either for malicious or good use.
Peter
-----Original Message-----
From: Brian Candler [mailto:B.Candler@pobox.com]
Sent: Wednesday, November 09, 2005 2:22 AM
To: Nick Kew
Cc: dev@httpd.apache.org
Subject: Re: pgp trust for https?
On Tue, Nov 08, 2005 at 12:46:18PM +0000, Nick Kew wrote:
> On Tuesday 08 November 2005 12:02, Brian Candler wrote:
>
> [twice - please don't]
Not sure what you mean by that. I probably did a group reply, so you got one
copy directly and one via the list. I'm afraid it's impossible to please
everyone on this point: some people insist on getting a direct reply (so
they see it sooner), and some people insist on replies to the list only.
Unfortunately my brain and my MUA are not able to record individual
preferences here, so everyone gets a 'G'roup reply.
> > > I'll sign my server. Same as I'll sign an httpd tarball if I roll one
> > > for public consumption. You sign your server. Where's the problem?
> >
> > The problem is that you'll have no protection against man-in-the-middle
> > attacks, whereby an attacker impersonates you, or intercepts your
traffic
> > (decrypting it and re-encrypting it, allowing them to read and/or modify
> > all communication on your supposedly 'secure' connection)
>
> Nonsense. The encryption is unaffected by this. It's only the server
> identity we're verifying.
Which fundamentally affects whether the encryption is actually performing
the job it was intended to do, namely to ensure that the data between the
two endpoints is (a) not visible to any other party, and (b) not subject to
tampering by any other party.
Simple example: attacker inserts a machine between the client and the server
(the archetypal "man in the middle" attack)
Client <----------------> attacker <--------------> Server
The client negotiates an encrypted session with the attacker, and the
attacker negotiates a separate encrypted session with the server.
The client *thinks* they are talking to the server, and that the session is
strongly encrypted (which it is). The server *thinks* it is talking to the
client, and that the session is strongly encrypted (it is).
In fact, the attacker can read *everything* which goes between the client
and the server - and either just copy it back and forth, or modify any parts
of it that it wishes. Both confidentiality and integrity have failed.
The fundamental problem is down to identity: can the client be sure it is
talking directly to the server, or is it talking to an imposter? Without
this assurance of identity, encryption is useless. Well, it's not 100%
useless because it protects you against passive attacks (sniffing only), but
you have to assume you're dealing with a *determined* attacker. These
man-in-the-middle attacks are trivial to implement, and there are toolkits
for doing so.
> > For example, an attacker could redirect requests for www.yourdomain.com
to
> > their server, perhaps by spoofing the DNS, or by unplugging the cable
> > somewhere between your ISP and your server and inserting their own
server.
> > Clients would be none the wiser.
>
> Nonsense. My server is signed with my (private) key. If they've got my
> key and passphrase, then the whole thing is dead, just as if they got
> my verispam certificate.
I think you're getting a bit confused - your "server" is a piece of hardware
plus software and is not signed (unless you are talking about some sort of
Trusted Computing Platform, which is a different ball game)
Your server has a private key, which you could think of as its digital
identity. You can give out the corresponding public key to anyone, and when
they communicate with you, you can prove that they are communicating
directly and securely to you, because you own the private key. The
man-in-the-middle is not possible if the client knows your public key in
advance, because the attacker doesn't know your private key; their server
would have a different private key and therefore reveal their identity to be
different.
If you have made prior arrangements with everyone that you communicate with,
so that they have a trustworthy copy of your public key (e.g. you handed it
to them in person on a floppy disk, and at the same time they were able to
prove to your satisfaction that the person in front of you was not an
imposter acting on behalf of an attacker), then your communication with
those parties is secure. Good for you.
So what about signing? Well, you could sign your own public key with your
own private key (self-signed certificate) or with a separate private key
which you keep for signing purposes (set up your own CA).
However the attacker can do the same on their server, so it's still not
possible to tell the difference between talking to the attacker or talking
to you unless the client already knows your public key. The signing doesn't
make any difference here, *unless* the client already has a copy of the
public key corresponding to the private key you used for signing, in which
case the signature validates the key. So now the client doesn't need your
server's public key, but they still do need to know your signing public key.
Passphrases? Well that prevents someone breaking into your office, stealing
your machine, and then setting up a clone somewhere else with the exact same
key. Good, but that doesn't affect that the client still needs to have
a-priori knowledge of your identity, or a way to verify it.
> > The attacker doesn't have your private key, so they would create their
own
> > key pair. As a result, the connecting client would see a *different* key
> > than the one they would see if they connect to your server directly. The
> > problem is, they have no way of telling which key is the one which
belongs
> > to you, and which one is the one which belongs to the attacker.
>
> Of course you do! That's exactly what the web of trust is all about.
> By your argument, I shouldn't be able to trust the httpd-2.1.9 tarball
> I downloaded about a week ago either - for exactly the same reason.
If it's PGP signed, and you have a degree of trust that the copy of the
public key you have really belongs to a trustworthy Apache developer, then
that's fine. You can obtain that trust by a number of routes. You might
exchange signed E-mails over a long period of time and via different routes
and mailboxes, and decide that it's unlikely that a man-in-the-middle attack
has being going on all this time for every message you exchanged. You might
meet them in person at a developer conference. Or the PGP key might be
PGP-signed by someone else who you trust to verify their identity.
Not all of these mechanisms are appropriate if you were going to
www.amazon.com and entering your credit card to order a book though. You
*might* know someone at Amazon personally; they *might* be sufficiently
technical to be able to find out the fingerprint of the public key used on
their SSL web servers, and print it out or give it to you personally; and
you *might* manually verify the authenticity of the key within your browser,
by calling up the certificate details page *every* time you connect to
Amazon, and manually comparing the key fingerprint with the one you were
given.
However, 99.99% of the rest of the web world doesn't work that way, as it's
just too painful. There are additional problems too (e.g. if the Amazon
techies decide to replace their keys with new ones, you will have to go
through the whole process again)
If you don't trust the third parties to do this work for you, and you insist
you want to do it yourself, that's fine. But I don't think you'll end up
buying anything over the Internet. You are of course free to choose not to
do so.
> > If the client knows you personally, they can phone you up and ask for
you
> > to read the key fingerprint over the phone, or fax it to them. That
doesn't
> > scale very well.
>
> And it's far more insecure. If I've nicked your webpage, whose 'phone
> or fax number do you suppose is on it? And how is telephone routing
> inherently any more secure than DNS, especially when so much of the
> former Free World is openly becoming police states.
The point about telephone calls is that you can recognise the voice of the
person you're talking to. It's one way to be able to convince yourself to a
sufficient degree that you're happy that the key you have really belongs to
the person you claim it's from. This applies equally to PGP, unless you're
going to rely only on third-party introductions.
Also, phone numbers can be obtained from printed directories. Yes, the
government might have replaced your copy of a directory with a modified one,
or the copy in your local library, or might be rerouting calls from your
phone (try using a payphone?) You have to assess the level of these risks
yourself. The more different routes of communication you use concurrently,
the more difficult it would be for a government to intercept them all
without you noticing.
Ultimately, even face-to-face meetings with strangers can't be trusted:
suppose someone intercepted your communication and sent an imposter to meet
you instead? You would need to convince yourself somehow that you are happy
to deal with this particular person. You can ask for identity documents, but
this ultimately still puts trust in government agencies. So you might just
want to establish a rapport until you can convince yourself just that this
is a person that you wish to deal with, and that they are not a very good
con artist acting on behalf of some malicious force.
Anyway, I think we're losing the point :-) With SSL you *need* to establish
the digital identity of the people you are communicating with, otherwise the
encryption is worthless as it is easily bypassed.
Regards,
Brian.
Re: pgp trust for https?
Posted by Brian Candler <B....@pobox.com>.
On Tue, Nov 08, 2005 at 12:46:18PM +0000, Nick Kew wrote:
> On Tuesday 08 November 2005 12:02, Brian Candler wrote:
>
> [twice - please don't]
Not sure what you mean by that. I probably did a group reply, so you got one
copy directly and one via the list. I'm afraid it's impossible to please
everyone on this point: some people insist on getting a direct reply (so
they see it sooner), and some people insist on replies to the list only.
Unfortunately my brain and my MUA are not able to record individual
preferences here, so everyone gets a 'G'roup reply.
> > > I'll sign my server. Same as I'll sign an httpd tarball if I roll one
> > > for public consumption. You sign your server. Where's the problem?
> >
> > The problem is that you'll have no protection against man-in-the-middle
> > attacks, whereby an attacker impersonates you, or intercepts your traffic
> > (decrypting it and re-encrypting it, allowing them to read and/or modify
> > all communication on your supposedly 'secure' connection)
>
> Nonsense. The encryption is unaffected by this. It's only the server
> identity we're verifying.
Which fundamentally affects whether the encryption is actually performing
the job it was intended to do, namely to ensure that the data between the
two endpoints is (a) not visible to any other party, and (b) not subject to
tampering by any other party.
Simple example: attacker inserts a machine between the client and the server
(the archetypal "man in the middle" attack)
Client <----------------> attacker <--------------> Server
The client negotiates an encrypted session with the attacker, and the
attacker negotiates a separate encrypted session with the server.
The client *thinks* they are talking to the server, and that the session is
strongly encrypted (which it is). The server *thinks* it is talking to the
client, and that the session is strongly encrypted (it is).
In fact, the attacker can read *everything* which goes between the client
and the server - and either just copy it back and forth, or modify any parts
of it that it wishes. Both confidentiality and integrity have failed.
The fundamental problem is down to identity: can the client be sure it is
talking directly to the server, or is it talking to an imposter? Without
this assurance of identity, encryption is useless. Well, it's not 100%
useless because it protects you against passive attacks (sniffing only), but
you have to assume you're dealing with a *determined* attacker. These
man-in-the-middle attacks are trivial to implement, and there are toolkits
for doing so.
> > For example, an attacker could redirect requests for www.yourdomain.com to
> > their server, perhaps by spoofing the DNS, or by unplugging the cable
> > somewhere between your ISP and your server and inserting their own server.
> > Clients would be none the wiser.
>
> Nonsense. My server is signed with my (private) key. If they've got my
> key and passphrase, then the whole thing is dead, just as if they got
> my verispam certificate.
I think you're getting a bit confused - your "server" is a piece of hardware
plus software and is not signed (unless you are talking about some sort of
Trusted Computing Platform, which is a different ball game)
Your server has a private key, which you could think of as its digital
identity. You can give out the corresponding public key to anyone, and when
they communicate with you, you can prove that they are communicating
directly and securely to you, because you own the private key. The
man-in-the-middle is not possible if the client knows your public key in
advance, because the attacker doesn't know your private key; their server
would have a different private key and therefore reveal their identity to be
different.
If you have made prior arrangements with everyone that you communicate with,
so that they have a trustworthy copy of your public key (e.g. you handed it
to them in person on a floppy disk, and at the same time they were able to
prove to your satisfaction that the person in front of you was not an
imposter acting on behalf of an attacker), then your communication with
those parties is secure. Good for you.
So what about signing? Well, you could sign your own public key with your
own private key (self-signed certificate) or with a separate private key
which you keep for signing purposes (set up your own CA).
However the attacker can do the same on their server, so it's still not
possible to tell the difference between talking to the attacker or talking
to you unless the client already knows your public key. The signing doesn't
make any difference here, *unless* the client already has a copy of the
public key corresponding to the private key you used for signing, in which
case the signature validates the key. So now the client doesn't need your
server's public key, but they still do need to know your signing public key.
Passphrases? Well that prevents someone breaking into your office, stealing
your machine, and then setting up a clone somewhere else with the exact same
key. Good, but that doesn't affect that the client still needs to have
a-priori knowledge of your identity, or a way to verify it.
> > The attacker doesn't have your private key, so they would create their own
> > key pair. As a result, the connecting client would see a *different* key
> > than the one they would see if they connect to your server directly. The
> > problem is, they have no way of telling which key is the one which belongs
> > to you, and which one is the one which belongs to the attacker.
>
> Of course you do! That's exactly what the web of trust is all about.
> By your argument, I shouldn't be able to trust the httpd-2.1.9 tarball
> I downloaded about a week ago either - for exactly the same reason.
If it's PGP signed, and you have a degree of trust that the copy of the
public key you have really belongs to a trustworthy Apache developer, then
that's fine. You can obtain that trust by a number of routes. You might
exchange signed E-mails over a long period of time and via different routes
and mailboxes, and decide that it's unlikely that a man-in-the-middle attack
has being going on all this time for every message you exchanged. You might
meet them in person at a developer conference. Or the PGP key might be
PGP-signed by someone else who you trust to verify their identity.
Not all of these mechanisms are appropriate if you were going to
www.amazon.com and entering your credit card to order a book though. You
*might* know someone at Amazon personally; they *might* be sufficiently
technical to be able to find out the fingerprint of the public key used on
their SSL web servers, and print it out or give it to you personally; and
you *might* manually verify the authenticity of the key within your browser,
by calling up the certificate details page *every* time you connect to
Amazon, and manually comparing the key fingerprint with the one you were
given.
However, 99.99% of the rest of the web world doesn't work that way, as it's
just too painful. There are additional problems too (e.g. if the Amazon
techies decide to replace their keys with new ones, you will have to go
through the whole process again)
If you don't trust the third parties to do this work for you, and you insist
you want to do it yourself, that's fine. But I don't think you'll end up
buying anything over the Internet. You are of course free to choose not to
do so.
> > If the client knows you personally, they can phone you up and ask for you
> > to read the key fingerprint over the phone, or fax it to them. That doesn't
> > scale very well.
>
> And it's far more insecure. If I've nicked your webpage, whose 'phone
> or fax number do you suppose is on it? And how is telephone routing
> inherently any more secure than DNS, especially when so much of the
> former Free World is openly becoming police states.
The point about telephone calls is that you can recognise the voice of the
person you're talking to. It's one way to be able to convince yourself to a
sufficient degree that you're happy that the key you have really belongs to
the person you claim it's from. This applies equally to PGP, unless you're
going to rely only on third-party introductions.
Also, phone numbers can be obtained from printed directories. Yes, the
government might have replaced your copy of a directory with a modified one,
or the copy in your local library, or might be rerouting calls from your
phone (try using a payphone?) You have to assess the level of these risks
yourself. The more different routes of communication you use concurrently,
the more difficult it would be for a government to intercept them all
without you noticing.
Ultimately, even face-to-face meetings with strangers can't be trusted:
suppose someone intercepted your communication and sent an imposter to meet
you instead? You would need to convince yourself somehow that you are happy
to deal with this particular person. You can ask for identity documents, but
this ultimately still puts trust in government agencies. So you might just
want to establish a rapport until you can convince yourself just that this
is a person that you wish to deal with, and that they are not a very good
con artist acting on behalf of some malicious force.
Anyway, I think we're losing the point :-) With SSL you *need* to establish
the digital identity of the people you are communicating with, otherwise the
encryption is worthless as it is easily bypassed.
Regards,
Brian.
Re: pgp trust for https?
Posted by Nick Kew <ni...@webthing.com>.
On Tuesday 08 November 2005 12:02, Brian Candler wrote:
[twice - please don't]
> On Sun, Nov 06, 2005 at 10:19:25PM +0000, Nick Kew wrote:
> > I'll sign my server. Same as I'll sign an httpd tarball if I roll one
> > for public consumption. You sign your server. Where's the problem?
>
> The problem is that you'll have no protection against man-in-the-middle
> attacks, whereby an attacker impersonates you, or intercepts your traffic
> (decrypting it and re-encrypting it, allowing them to read and/or modify
> all communication on your supposedly 'secure' connection)
Nonsense. The encryption is unaffected by this. It's only the server
identity we're verifying.
> For example, an attacker could redirect requests for www.yourdomain.com to
> their server, perhaps by spoofing the DNS, or by unplugging the cable
> somewhere between your ISP and your server and inserting their own server.
> Clients would be none the wiser.
Nonsense. My server is signed with my (private) key. If they've got my
key and passphrase, then the whole thing is dead, just as if they got
my verispam certificate.
> The attacker doesn't have your private key, so they would create their own
> key pair. As a result, the connecting client would see a *different* key
> than the one they would see if they connect to your server directly. The
> problem is, they have no way of telling which key is the one which belongs
> to you, and which one is the one which belongs to the attacker.
Of course you do! That's exactly what the web of trust is all about.
By your argument, I shouldn't be able to trust the httpd-2.1.9 tarball
I downloaded about a week ago either - for exactly the same reason.
> If the client knows you personally, they can phone you up and ask for you
> to read the key fingerprint over the phone, or fax it to them. That doesn't
> scale very well.
And it's far more insecure. If I've nicked your webpage, whose 'phone
or fax number do you suppose is on it? And how is telephone routing
inherently any more secure than DNS, especially when so much of the
former Free World is openly becoming police states.
> So generally the client has to rely on a third-party to sign the key:
wtf do you suppose PGP is all about? Please see
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=113131552325973&w=2
--
Nick Kew
Re: pgp trust for https?
Posted by Brian Candler <B....@pobox.com>.
On Sun, Nov 06, 2005 at 10:19:25PM +0000, Nick Kew wrote:
> I'll sign my server. Same as I'll sign an httpd tarball if I roll one
> for public consumption. You sign your server. Where's the problem?
The problem is that you'll have no protection against man-in-the-middle
attacks, whereby an attacker impersonates you, or intercepts your traffic
(decrypting it and re-encrypting it, allowing them to read and/or modify all
communication on your supposedly 'secure' connection)
For example, an attacker could redirect requests for www.yourdomain.com to
their server, perhaps by spoofing the DNS, or by unplugging the cable
somewhere between your ISP and your server and inserting their own server.
Clients would be none the wiser.
The attacker doesn't have your private key, so they would create their own
key pair. As a result, the connecting client would see a *different* key
than the one they would see if they connect to your server directly. The
problem is, they have no way of telling which key is the one which belongs
to you, and which one is the one which belongs to the attacker.
If the client knows you personally, they can phone you up and ask for you to
read the key fingerprint over the phone, or fax it to them. That doesn't
scale very well.
So generally the client has to rely on a third-party to sign the key: they
trust the third-party to check your identity (i.e. you are the person who
really owns www.yourdomain.com), and then they sign your key to confirm that
you are the real owner. The attacker's key won't be signed, so the client's
browser can tell the difference between your server and the attacker's
server.
Regards,
Brian.
Re: pgp trust for https?
Posted by Phillip Susi <ps...@cfl.rr.com>.
Nick Kew wrote:
>Huh? The same person who installs the cert now. It's just a different
>signature. And for those who want a certificate authority, have such
>authorities (the more the better) sign *their* PGP keys.
>
>
>
>>From whomsoever is responsible for it. Maybe even more than one
>individual, in the case of an org with lots of techies.
>
>
>
>I'll sign my server. Same as I'll sign an httpd tarball if I roll one
>for public consumption. You sign your server. Where's the problem?
>
>
>
>I don't want to get involved in something where I have nothing substantial
>and new to contribute. "Encourage others to trust you" is a marketing
>job of which I would be totally incapable.
>
>
>
>
>
Now you seem to be talking about self signed certificates. There are
sites out there that use them, but the problem is, they provide no
authentication. Sure, they allow encrypted communications, and if you
save the certificate, then you can be sure that you are connecting to
the same server the next time ( preventing man in the middle attacks )
but there's nothing to prevent a man in the middle the first time.
Another example you mentioned is signing tarballs you make. Well if
your certificate is not signed by a trusted third party, such as
verisign or whomever, then how am I to know that it was YOU who signed
it and not some random guy claiming to be you? Anyone can make a
keypair, the signature of the CA is what authenticates it.
>Any particular government? A few years ago I'd probably have agreed.
>With the most blatently corrupt government in living memory, that has
>less appeal.
>
>
>
True, but if things are that bad then you have bigger problems to worry
about. As long as you still trust them to issue forms of paper
identification, then digital ones should be no different. Why get a
paper ID from the government to show to a CA to prove you are you, so
they can sign your cert, rather than just have the gov't sign it directly?
>
>Sure. I do trust my own key, and those of quite a number of other people,
>including, for example, most of those with whom I would expect to share
>an SVN repository for development work. That's the kind of application
>where a PGP-signed server key is a clear winner.
>
>
How so? Again, in a small group of people who know each other in real
life and have a secure method of exchanting certificates, that works
fine, but this breaks down when you have a larger group of people who do
not know each other in real life and can swap their certs on disks when
they see each other.
>And when my browser indicates that I don't trust a key, I can investigate
>in detail by fetching the public key and its signature(s), and make whatever
>other checks I see fit. Exactly the same as when I download a package
>from the 'net.
>
>
>
Yes... and you can do that with the x.509 certificates that are used for
https/SSL, so what's pgp needed for?
Re: pgp trust for https?
Posted by Nick Kew <ni...@webthing.com>.
On Sunday 06 November 2005 21:41, Phillip Susi wrote:
> Nick Kew wrote:
> >Why would anyone have to do that? I'll trust a server as much as I trust
> >the PGP key of the person who signed it. That's the same as trusting
> >an httpd download because it's signed by someone whose key I trust.
>
> The question then is who is going to sign?
Huh? The same person who installs the cert now. It's just a different
signature. And for those who want a certificate authority, have such
authorities (the more the better) sign *their* PGP keys.
> You seem to be sugesting
> that a server accept signatures from anyone and everyone,
From whomsoever is responsible for it. Maybe even more than one
individual, in the case of an org with lots of techies.
> and you would
> only trust the server if someone that you know and trust had already
> decided to trust the server and sign their certificate. That still
> leaves you in a position of either deciding to implicitly trust the site
> and sign it's certificate, which then causes all of your friends to
> trust it, or trusting the opinion of your friend who already decided (
> based on what exactly? ) to trust the site and sign their cert.
I'll sign my server. Same as I'll sign an httpd tarball if I roll one
for public consumption. You sign your server. Where's the problem?
> >It's usually signed by verispam, who make a habit of engaging in some
> >very nasty business practices, from spamming to holding the 'net to
> >ransom. They also bought the main competitor (thawte), leaving us
> >short of competition amongst those widely recognised by browsers.
> >
> >With PGP it's my own trust, not theirs.
>
> You are quite free to set up your own root CA and encorage others to
> trust you.
I don't want to get involved in something where I have nothing substantial
and new to contribute. "Encourage others to trust you" is a marketing
job of which I would be totally incapable.
> You are also free to decide to NOT trust certificates signed
> by verispam. Personally, I feel this role belongs in the government.
> That's where you get your birth certificate, driver's license, social
> security card, and other forms of 'official' ID. They may as well get
> rid of all the paper ID and just start issuing digital certificates.
Any particular government? A few years ago I'd probably have agreed.
With the most blatently corrupt government in living memory, that has
less appeal.
> >I seldom use pgp for email (and I hate it when people sign messages
> >posted to a list like this). But I always use it to verify software I
> >download from the 'net. And, unlike https, it tells me every time
> >whether or not *I* trust the digital signature.
>
> How do you decide that such a signature is trustworthy and valid? You
> either have to know about their public key a priori, or know ( and trust
> ) another one that signed theirs, otherwise, you're just guessing that
> you can trust it.
Sure. I do trust my own key, and those of quite a number of other people,
including, for example, most of those with whom I would expect to share
an SVN repository for development work. That's the kind of application
where a PGP-signed server key is a clear winner.
And when my browser indicates that I don't trust a key, I can investigate
in detail by fetching the public key and its signature(s), and make whatever
other checks I see fit. Exactly the same as when I download a package
from the 'net.
--
Nick Kew
Re: pgp trust for https?
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
> Personally, I feel this role belongs in the government.
Whose government? I don't even trust my own government, so why should I trust
a foreign government?
Joost
Re: pgp trust for https?
Posted by Brian Candler <B....@pobox.com>.
On Sun, Nov 06, 2005 at 05:31:13PM -0500, Peter Djalaliev wrote:
> However, I really think that PGP and the web-of-trust has
> applicability and usefulness for web sites. For a smaller web site,
> obtaining a certificate of sufficient level is quite hard and
> expensive. These websites usually end up running their own CA-s. If
> we can replace all these "rogue" certificate authorities by using PGP
> and the web-of-trust, maybe we can achieve a better security model.
> What do you think?
Have you seen www.cacert.org ?
Free certificates derived from a distributed web of trust. Of course,
browsers need to have the cacert.org root certificate installed.
Regards,
Brian.
Re: pgp trust for https?
Posted by Peter Djalaliev <pe...@gmail.com>.
It is a little unclear to me about the combination of security and
efficiency that we can achieve by using PGP keys and the web-of-trust on the
web. Imagine connecting to you bank or online stock broker. If they would
certify themselves using PGP certificates, they will need to have a large
number of certificates in order for their clients to trust their identity.
Verifying their identity exclusively is just too important to depend on "the
word of mouth", which is in a way what the web-of-trust gives us.
I am not familiar with the the business practices of CA's, but I can imagine
how they could get by with having nasty business practices. However, imagine
youself being a big bank. Would rather have to deal with a web of trust and
possible thousands or more certificates, or would you pay a flat fee to a
certifying authority?
Along these lines, I agree with Phillip that the government should be a
certificate authority. They do identity, adress, etc. checks when they issue
documents anyway. Issuing a certificate with your public key can just be
another service that they can provide. This can solve the problem of the
unfair business practices used by certifying authorities.
However, I really think that PGP and the web-of-trust has applicability and
usefulness for web sites. For a smaller web site, obtaining a certificate of
sufficient level is quite hard and expensive. These websites usually end up
running their own CA-s. If we can replace all these "rogue" certificate
authorities by using PGP and the web-of-trust, maybe we can achieve a better
security model.
What do you think?
Peter
Re: pgp trust for https?
Posted by Phillip Susi <ps...@cfl.rr.com>.
Nick Kew wrote:
>Why would anyone have to do that? I'll trust a server as much as I trust
>the PGP key of the person who signed it. That's the same as trusting
>an httpd download because it's signed by someone whose key I trust.
>
>
>
The question then is who is going to sign? You seem to be sugesting
that a server accept signatures from anyone and everyone, and you would
only trust the server if someone that you know and trust had already
decided to trust the server and sign their certificate. That still
leaves you in a position of either deciding to implicitly trust the site
and sign it's certificate, which then causes all of your friends to
trust it, or trusting the opinion of your friend who already decided (
based on what exactly? ) to trust the site and sign their cert.
That doesn't provide much in the way of security, and is impossible to
maintain -- a site can't accept a million signatures on their
certificate from everyone who feels like signing it.
>It's usually signed by verispam, who make a habit of engaging in some
>very nasty business practices, from spamming to holding the 'net to
>ransom. They also bought the main competitor (thawte), leaving us
>short of competition amongst those widely recognised by browsers.
>
>With PGP it's my own trust, not theirs.
>
>
>
You are quite free to set up your own root CA and encorage others to
trust you. You are also free to decide to NOT trust certificates signed
by verispam. Personally, I feel this role belongs in the government.
That's where you get your birth certificate, driver's license, social
security card, and other forms of 'official' ID. They may as well get
rid of all the paper ID and just start issuing digital certificates.
>I seldom use pgp for email (and I hate it when people sign messages
>posted to a list like this). But I always use it to verify software I
>download from the 'net. And, unlike https, it tells me every time
>whether or not *I* trust the digital signature.
>
>
>
>
How do you decide that such a signature is trustworthy and valid? You
either have to know about their public key a priori, or know ( and trust
) another one that signed theirs, otherwise, you're just guessing that
you can trust it.
Re: pgp trust for https?
Posted by Nick Kew <ni...@webthing.com>.
On Saturday 05 November 2005 23:28, Phillip Susi wrote:
> The big reason that comes to my mind is that users don't want to have to
> implicitly trust the server from the start, then register on the site by
> uploading their own key before secure communications can begin.
Why would anyone have to do that? I'll trust a server as much as I trust
the PGP key of the person who signed it. That's the same as trusting
an httpd download because it's signed by someone whose key I trust.
> The big advantage of a public certificate infrastructure is that the
> rest of us can trust someone we have never met before ( i.e. an https
> server you have never visited before ) because they present us with a
> certificate that is signed by a trusted third party.
It's usually signed by verispam, who make a habit of engaging in some
very nasty business practices, from spamming to holding the 'net to
ransom. They also bought the main competitor (thawte), leaving us
short of competition amongst those widely recognised by browsers.
With PGP it's my own trust, not theirs.
> Personally, I don't understand the need for pgp. You can sign and
> encrypt email or IPsec just fine using x.509 certificates.
I seldom use pgp for email (and I hate it when people sign messages
posted to a list like this). But I always use it to verify software I
download from the 'net. And, unlike https, it tells me every time
whether or not *I* trust the digital signature.
--
Nick Kew
Re: pgp trust for https?
Posted by Phillip Susi <ps...@cfl.rr.com>.
The big reason that comes to my mind is that users don't want to have to
implicitly trust the server from the start, then register on the site by
uploading their own key before secure communications can begin.
The big advantage of a public certificate infrastructure is that the
rest of us can trust someone we have never met before ( i.e. an https
server you have never visited before ) because they present us with a
certificate that is signed by a trusted third party. The server proves
to the client that it is who it says it is, and the client can
optionally prove its identity to the server with a client certificate.
Either one allows all communications to be encrypted and you don't have
to exchange private information first to do it.
Personally, I don't understand the need for pgp. You can sign and
encrypt email or IPsec just fine using x.509 certificates.
Nick Kew wrote:
>We have grown accustomed to two separate trust mechanisms
>on the 'net; server certs signed by some authority, or the PGP
>web of trust.
>
>I would like to be able to use PGP trust over the web. That would
>mean (something like) installing a certificate on the server, and
>signing it with my PGP key. My browser, having access to and
>trust in, my public key, will then trust the server. No need for
>any dealings with verispam.
>
>Is there any technical reason this shouldn't happen?
>
>
>
Re: pgp trust for https?
Posted by Rachel Willmer <rw...@gmail.com>.
To add a bit more detail to Ben's mail, OpenPGP:SDK is a new open
source library, available under a Apache-style license. It's a
completely new implementation of the OpenPGP spec, and is available at
<http://openpgp.nominet.org.uk>.
At EuroOSCon, we discussed a number of applications which could be
developed using such a library - using PGP keys inside the X509
certificate for web authentication was one such application we used as
an example.
If you're interested in writing such an application, please take a
look at OpenPGP:SDK. We might well write a demo of this ourselves, but
it's a question of priorities at the moment, so no guarantees about
when...
Rachel
Re: pgp trust for https?
Posted by Ben Laurie <be...@algroup.co.uk>.
Nick Kew wrote:
> We have grown accustomed to two separate trust mechanisms
> on the 'net; server certs signed by some authority, or the PGP
> web of trust.
>
> I would like to be able to use PGP trust over the web. That would
> mean (something like) installing a certificate on the server, and
> signing it with my PGP key. My browser, having access to and
> trust in, my public key, will then trust the server. No need for
> any dealings with verispam.
>
> Is there any technical reason this shouldn't happen?
No, in fact its one of the things we spoke about at EuroOSCon when
announcing OpenPGP:SDK.