Using email to validate SSL cert requests (was Re: CAcert Root Certificate)
Nelson B
the last few weeks have gotten so deep that mozilla can no longer
show the tree/hierarchy of messages/replies. So, please, let's
use new threads for new topics.)
In a recent post, someone here attempted to defend the practice of
using insecure email as the sole means of confirming the legitimacy
of a request for an SSL server certificate. I'm here to challenge
that. I think it's SO BAD a practice, in fact, that I think mozilla
should specifically say, in the policy, that that's not good enough
for a CA that is admitted to mozilla's trusted root list. I am not
targetting any particular CA here. I think this is a matter of policy
for all CAs.
David Stutzman wrote:
> For them to issue you an SSL cert you have to add the domain to your
> account. When you want to add a domain you put in the domain name
> (example.com) and then it offers you a choice of verification addresses of:
>
> ro...@example.com
> hostmasterexample.com
> postm...@example.com
> ad...@example.com
> webm...@example.com
>
> which it then sends an email to the chosen address. In the browser it
> says:
>
> The domain 'example.com' has been added to the system, however before
> any certificates for this can be issued you need to open the link in a
> browser that has been sent to your email address.
[snip]
> This means I can't start getting amazon.com ssl certs unless I have
> control over one of the administrative email boxes of amazon.com and if
> *that* is the case then either I work for Amazon and this is valid or
> Amazon has other things to worry about than rogue sites such as their
> email system's security.
Just over a year ago, someone published an article in a quarterly
journal exposing just how easy it is to hijack the email for a domain.
Read a draft of it at http://files.juraj.bednar.sk/CA
In his article, he documented a case in point, where he did it, and
*succesfully got an SSL server cert for a domain that he did not own,*
from a CA that was using email as the only means of verification for
SSL server certs.
He explained several ways that he could have done it, and detailed the
one means by which he did it. (He had gotten permission from the
domain's rightful owner first, but had not used that permission in
accomplishing anything that he did. He could have done it all without
permission. He explained all this in his article.)
There are many more domains and web servers than there are bad guys, so
the bad guys don't have time to attack them all. The bad guys mostly
go after the big value targets first. So, lots of people whose email
accounts are low value targets can get by without using any security
measures whatsoever, because they aren't under attack. And they can
point (perhaps in large numbers) to the security (absence of attack,
successful or not) they have enjoyed without any measures whatsoever.
But SSL, with its "128 bit" crypto, is about resistance from attack by
determined attackers, including people with the computational
resources to break a mere 40-bit key. People who go to the bother to
deploy such strong resistance to attack are often high value targets,
but high value or not, they want to succesfully resist attacks of
that magnitude and *ALL easier attacks*.
It has been demonstrated that an attack on an email domain is orders
of magnitude easier than attacks on SSL. So, if an attacker wanted
to attack a high value target, he would surely attack the email
channels before attempting to attack the crypto.
The point is that all that "128-bit crypto" isn't worth a penny if
the attacker can get a falsified cert by a simple email channel
attack. Giving out strong SSL server certs on the basis of
authentication no stronger than insecure email is like building a
vault on a foundation of straw. It may be ok for vaults that
contain no more than straw, but isn't ok for the rest.
And if browser users ("relying parties") cannot tell the difference
between certs from CAs that base their authentication on no more
than insecure email, woe be to them!
So, If I was a CA trying to be admitted to (or stay in) mozilla's
list of trusted CAs, I wouldn't brag about, or attempt to defend,
my issuance of SSL server certs based on mere untrusted email for
authentication.
--
Nelson B
C. D. Rok
> In a recent post, someone here attempted to defend the practice of
> using insecure email as the sole means of confirming the legitimacy
> of a request for an SSL server certificate. I'm here to challenge
> that. I think it's SO BAD a practice, in fact, that I think mozilla
> should specifically say, in the policy, that that's not good enough
> for a CA that is admitted to mozilla's trusted root list. I am not
> targetting any particular CA here. I think this is a matter of policy
> for all CAs.
There are two paradigms:
a) An identity exists as a meta-category, and someone or something has
to ensure that the certificate is issued with a name that without any
possibility of doubt or error maps to that meta-identity.
b) A certificate has a unique identifier (a "name") and all that the
certificate ensures is that the combination of certificate issuer
identification and the name associated with the certificate is
unique.
Paradigm (a) is naive and will never work in practice.
Paradigm (b) is what we must accept and learn to work with.
CD Rok
Duane
> b) A certificate has a unique identifier (a "name") and all that the
> certificate ensures is that the combination of certificate issuer
> identification and the name associated with the certificate is
> unique.
> Paradigm (b) is what we must accept and learn to work with.
Names by themselves aren't in most cases unique, unless you're refering
to some abstract suggestion of making them unique some how, such as a
combination of name + email address, or name + email + govt ID #...
--
Best regards,
Duane
http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers
"In the long run the pessimist may be proved right,
but the optimist has a better time on the trip."
Richard Freeman
> In a recent post, someone here attempted to defend the practice of
> using insecure email as the sole means of confirming the legitimacy
> of a request for an SSL server certificate. I'm here to challenge
> that. I think it's SO BAD a practice, in fact, that I think mozilla
> should specifically say, in the policy, that that's not good enough
> for a CA that is admitted to mozilla's trusted root list. I am not
> targetting any particular CA here. I think this is a matter of policy
> for all CAs.
I think the cert-by-email practice could work with suitable safeguards.
It all depends on what we're certifying. Are we saying that you are
connected to example.com, or that you're connected to a server owned by the
human being who bought example.com?
The first prevents man-in-the-middle attacks, and the second prevents
phishing over SSL (or at least makes it easy to find out who the guilty
party is). The first probably can be done via email. The second would
probably require an in-person visit with government-issued ID (possibly
more than one form). Anything less than visual inspection of ID by a
trusted party would make the system unsuitable for prosecuting somebody
based on abuse of SSL identity - which is what you need to stop phishing.
I'm not under the impression that the mainstream vendors do in-person ID
checks. So, we don't have that level of protection currently.
I think that domain control can be reliably verified using email. I agree
that domains can be hijacked - but there are solutions to this:
1. You sign up via a website. The website sends you an email containing a
verification link. All communications are signed, and include a copy of
the certificate request.
2. They repeat this at a few intervals over a week or two. At random
times.
In order to hijack your domain, an attacker would have to be able to
intercept your email over a several days. By including the request in the
email you might be able to prevent more subtle MITM attacks (I'm not 100%
sure this is even necessary - I have a few scenarios in mind but they're
probably not possible in practice).
While somebody might be able to hijack your domain for an hour to get a
cert, I doubt they could maintain this for weeks at a time and avoid
detection.
I'm all for having controls on the use of email - but I'm not sure that the
solution is to ditch it entirely.
I guess it really depends on what you want SSL certs to prove. I'd argue
that right now they don't meet the standard some people are proposing - so
why worry about lowering the standard?
The only way we're going to have really strong SSL certs would be if
governments issued them and they were kept exclusively on smartcards so
that the average member of the public wouldn't let them get out of control.
That isn't going to happen soon (although one day it might - it would be a
big hurdle against identity theft). You could have your webserver generate
a CSR and then sign it yourself using your government-issued ID (that way
you don't have to leave your ID card in your computer all the time). You
could revoke your webserver at any time, and the government could revoke
your ID at any time. Oh well, we can dream at least, can't we?
Duane
> While somebody might be able to hijack your domain for an hour to get a
> cert, I doubt they could maintain this for weeks at a time and avoid
> detection.
Actually this is another issue, if they can hijack your email for an
hour they can hijack your domain for life as most registrars send
passwords, changes to your domain name in plain text emails...
Ian G
>I think the cert-by-email practice could work with suitable safeguards.
>
>
Yes, I was thinking something along these lines.
Nelson was for proposing more stringent ways
to tie down the "identity" than email because of
the fairly easy to spot difficulties. It's very true
that email isn't that strong, but survives where
people are being a little careful and it doesn't
really matter.
I think the main way this works in the auditing
world is:
a. make a statement about what you are doing,
b. show how you keep to that statement.
So if the statement is "we check the email only."
then it's easy to meet, as well as being a low
standard. If however the standard is that "we
check that you can trust in sending your CC to
this business" then it's a high standard, and is
also a lot more work in showing.
The question then is, what is the statement that,
say Verisign makes, as opposed to CACert, and
do we accept the differences, or do we want them
to be the same?
This is a big dilemma. I can't see a world where
all CAs do the same thing! But I also can't see
a world (yet) where we can show the users the
difference.
>It all depends on what we're certifying. Are we saying that you are
>connected to example.com, or that you're connected to a server owned by the
>human being who bought example.com?
>
>The first prevents man-in-the-middle attacks, and the second prevents
>phishing over SSL (or at least makes it easy to find out who the guilty
>party is). The first probably can be done via email. The second would
>probably require an in-person visit with government-issued ID (possibly
>more than one form). Anything less than visual inspection of ID by a
>trusted party would make the system unsuitable for prosecuting somebody
>based on abuse of SSL identity - which is what you need to stop phishing.
>
>
Right. Now, I'm scratching my head on this one,
where in the SSL world or the CA world does it
say that the business identity is the thing being
checked? Is this something that just ... emerged?
We know the domain name is being checked, and
we can trace this to the cryptographic security
model of SSL: It provides encryption in order to
stop eavesdroppers. In order to overcome spoofing
(a.k.a. MITM) the domain name is checked in the
cert.
But, the cryptosystem only asks for the domain
name to be checked ... primarily I think because
in those days it was fairly obvious that anyone
could easily hijack DNS and DNS resisted easy
fixing (still does!).
So the central question is: domain name or
business identity?
[snip]
>1. You sign up via a website. The website sends you an email containing a
>verification link. All communications are signed, and include a copy of
>the certificate request.
>2. They repeat this at a few intervals over a week or two. At random
>times.
>
>
The other thing that can be done is to prove
ownership of the website. Ask the cert provider
to insert XXX into the HTML of the domain's page.
In fact, it is common practice to "offer deals" to
people if they put their logo on the site in a small
tasteful corner (Intel Inside meets viral marketing).
So CACert would say: ok, first step, put this logo
on your site [proudly using CACert]. Then send
us the CSR....
>I guess it really depends on what you want SSL certs to prove. I'd argue
>that right now they don't meet the standard some people are proposing - so
>why worry about lowering the standard?
>
>
I would be surprised if phishers couldn't walk
through the major CA's practices right now like
chocolate through a goose... There's a huge
difference between selling certs to honest
people and putting up a facade of faxed paper
work, and having to deal with people who will
basically lie about anything to get your cert.
Phishers are experts in creating forged info,
remember.
>The only way we're going to have really strong SSL certs would be if
>governments issued them and they were kept exclusively on smartcards so
>that the average member of the public wouldn't let them get out of control.
>
>
LOL.... be careful what you wish for!
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Duane
> We know the domain name is being checked, and
> we can trace this to the cryptographic security
> model of SSL: It provides encryption in order to
> stop eavesdroppers. In order to overcome spoofing
> (a.k.a. MITM) the domain name is checked in the
> cert.
While the browser doesn't warn fingerprints have changed I don't see how
man in the middle attacks can be noticed/prevented/known about, this is
one really strong point SSH has over SSL, the fact it actively warns you
about something changing and that there could be a man in the middle
attack occurring, or had occurred in the past. Usually it just means
host keys have changed, but without this information it is VERY
difficult to identify this attack at present.
I'm kinda surprised you haven't made more noise about this when you made
mention previously about some CAs offering snooping services to govt's
and being a conflict of interest.
> I would be surprised if phishers couldn't walk
> through the major CA's practices right now like
> chocolate through a goose... There's a huge
So on one hand you are suggesting we foist problems onto CAs and on the
other you show how that won't stop problems. So how is it forcing
problems onto CAs is going to fix anything? :)
Ian G
> I'm kinda surprised you haven't made more noise about this when you
> made mention previously about some CAs offering snooping services to
> govt's and being a conflict of interest.
:-) Well, it is because we are making some
forward progress. The fact that the system
has some gaping holes in it needs to be
balanced alongside the fact that it *is* the
system, and AFAICS, it is the only hope for
dealing with phishing.
What's taken me a long time to discover is
that there are more people who actually
do agree with the flaws than I can see. So,
in a sense, let's forget the job of needing
to hammer on the flaws, and start thinking
of the fixes ... in such a way that they improve
the product.
>> I would be surprised if phishers couldn't walk
>> through the major CA's practices right now like
>> chocolate through a goose... There's a huge
>
>
> So on one hand you are suggesting we foist problems onto CAs and on
> the other you show how that won't stop problems. So how is it forcing
> problems onto CAs is going to fix anything? :)
If I had a wife she would agree with you :)
Here's the thing. If you've been following
the phishing adventure for the last 2 years,
as I have, after a while you get to understand
the measure of it. And where it's heading....
We do have the dilemma that phishing is
heading in a certain direction: to more acute
and direct attacks on the browser's crypto
system. Right now it bypasses it totally, so
we don't notice.
The Shmoo bug has shown all that in context.
It's drawn a nice line from phishing to HTML
to HTTPS to the user.
So, if you accept that phishing is going to
be forced in the direction of attacking the
CAs to fraudulently acquire certs, what to
do about it?
Well, we have to start protecting the CA's
space and patch. To do that, we have to
create the branded space that the CA can
protect; in order to give the CA what he
needs to protect himself, we must let him
define himself to the users. Ergo, as Bob
pointed out, the original security model.
Once the CA has a space to defend, he can
figure out how to defend it. It might mean
he has to change his business model, or to
change his CPS/CP stuff. Or whatever. But
at least he can do it. At the moment, a CA
cannot defend himself because he isn't
defined. There is no clear definition of what
a CA does ... c.f., the domain v. identity
discussion, cross-borders differences, and
conflicts of interest. But once the branding
is in place, the CA and the market and the
users will create that definition. Which can
then be defended.
If none of that makes sense, think think of
how innoculation works. My current view
is that we have a period during which we
can innoculate the CA system. Do not fight
too hard against a few minor but honest
problems ... because the result will strengthen
the body for the future real battle.
Duane
> What's taken me a long time to discover is
> that there are more people who actually
> do agree with the flaws than I can see. So,
> in a sense, let's forget the job of needing
> to hammer on the flaws, and start thinking
> of the fixes ... in such a way that they improve
> the product.
But tracking finger prints is a solution to one problem, it's a jigsaw
puzzle, fixing one piece doesn't help you have to attack things as a
total of all the pieces...
> Well, we have to start protecting the CA's
> space and patch. To do that, we have to
> create the branded space that the CA can
> protect; in order to give the CA what he
> needs to protect himself, we must let him
> define himself to the users. Ergo, as Bob
> pointed out, the original security model.
But this particular problem is a registrar/registry/browser issue, not a
CA issue, if you fix the problem, and not come up with band-aides that
inflict problems onto unrelated parties everyone will be better off.
You call for branding of CAs, but not branding of registrars/registries,
why not slug them up on the chrome as well and maybe they'd start caring
about dodgy domains too.
Ian G
> ....
> Just over a year ago, someone published an article in a quarterly
> journal exposing just how easy it is to hijack the email for a domain.
> Read a draft of it at http://files.juraj.bednar.sk/CA
An interesting read. He brings up an awful lot
of problems.
Using a combination of techniques is probably
as good as it gets. But even then, this is not
going to stop a fraudulent issue. What's worse,
it may discriminate in ways that we would rather
avoid, given MF's mission to deliver to the world.
Digression: I lived for 4 years in a country without
streetnames. There were no addresses, because
there was no postal delivery. If you wanted to get
mail you had to go order a post office box or share
one. The electricity bill was not in my name, and
in fact I couldn't get a single piece of paper that
proved I lived in my house. Nor did the company.
So much so that when we as a business moved half
a dozen countries down the road (well, island chain)
some of our team asked for the privilege of paying
the new electricity bill so they could get some proof
of existence.
This "documents" situation exists in a large
proportion of the world. Wherever we are, we
should consider the fact that elsewhere, it's
just 'different.' How are you going to sell an
SSL cert to someone who can't prove who they
are? Or, are we saying SSL is only available for
those who follow our western notions of identity
proof?
(This problem becomes really dramatic when
trying to open bank accounts or digital money
accounts.)
> It has been demonstrated that an attack on an email domain is orders
> of magnitude easier than attacks on SSL. So, if an attacker wanted
> to attack a high value target, he would surely attack the email
> channels before attempting to attack the crypto.
That's Adi Shamir's 3rd law of security:
Cryptography is typically bypassed, not penetrated
http://www.financialcryptography.com/mt/archives/000147.html
....
> And if browser users ("relying parties") cannot tell the difference
> between certs from CAs that base their authentication on no more
> than insecure email, woe be to them!
Hallelujah to that!
Duane
> This "documents" situation exists in a large
> proportion of the world. Wherever we are, we
> should consider the fact that elsewhere, it's
> just 'different.' How are you going to sell an
> SSL cert to someone who can't prove who they
> are? Or, are we saying SSL is only available for
> those who follow our western notions of identity
> proof?
I'm starting to get the feeling that some people are implying this, and
things have gone back to being a flat earth that the sun resolves
around... We both keep stating (as far as I can remember, which is about
3 seconds ago) that there is no 1 size fits all, and binary security
sucks and has no hope of representing this... I don't think sticking a
logo on the chrome will fix this issue either...
Nelson pointed out how bad email verification is, but what if that's all
you can prove?
Ian G
> Nelson pointed out how bad email verification is, but what if that's
> all you can prove?
If email is the only use for the cert, one could make
a case that is good enough.
If HTTPS is the use for the cert, then as I suggested
in some other random long rant today (!) we could
always ask the domain owner to stick something in
the HTTP page.
Sort of like a little icon ad that people commonly do,
you can see a couple of them in the below link. I
think that makes a case that whoever stuck those
in there has at least some control over the domain,
for HTTP purposes.
Ram0502
I don't think that the two you list are the only two options. To me
they read as the two sides of the binary assertions "we can depend on
perfection from this part of the system." If I used the two suggested
models as my only options in the pedestrian world I would never use a
credit card in a store as I could not be assured a means of insurance
or protection from fraud; instead the credit card system relies on the
interaction of sub-perfect. When you soften (a) to require a high
probability of accuracy rather than perfection you end up with a
component you can build on.
Ram0502
> Duane wrote:
>
> > Nelson pointed out how bad email verification is, but what if
that's
> > all you can prove?
>
>
> If email is the only use for the cert, one could make
> a case that is good enough.
I agree if your only concern is the email address of the sender or
recipient (e.g. maintain an ongoing discussion albeit anonymously) or
the establishment of a re-usable 'trust session' with someone you will
authenticate through other out of scope mechanisms.
>
> If HTTPS is the use for the cert, then as I suggested
> in some other random long rant today (!) we could
> always ask the domain owner to stick something in
> the HTTP page.
That's an interesting suggestion, it provides the same kind of
authentication for HTTPS as the above does for secure email. If the
session is initiated by the CA this proves the ability to control the
host at the specified location. I wouldn't give them my CC# but it does
create a relationship. I wouldn't provide any sensitive information to
them as they could be hard to track down if were facing fraud as
presumably I wouldn't know their identity.
Duane
> That's an interesting suggestion, it provides the same kind of
> authentication for HTTPS as the above does for secure email. If the
> session is initiated by the CA this proves the ability to control the
> host at the specified location. I wouldn't give them my CC# but it does
> create a relationship. I wouldn't provide any sensitive information to
> them as they could be hard to track down if were facing fraud as
> presumably I wouldn't know their identity.
But what if the certificate is only used to protect passwords for
webmail and doesn't need the ability to be found for fraud?
Binary security can't deal with both situations simutaniously and
adequately, it needs to indicate visually the level of security...
C. D. Rok
>>There are two paradigms:
>>a) An identity exists as a meta-category, and someone or something
> I don't think that the two you list are the only two options. To me
> they read as the two sides of the binary assertions "we can depend on
> When you soften (a) to require a high
> probability of accuracy rather than perfection you end up with a
> component you can build on.
"High probability" is good enough for manual transactions - such as the
credit cards in a store... But when a small level of uncertainty opens a
possibility for *huge* exploits, the confidence level better as high as
possible.
Presenting the site's key fingerprint to the user as a matter of course
seems more and more like something that can not be avoided.
CDR
Ram0502
> Ram0502 wrote:
> >>There are two paradigms:
> >>a) An identity exists as a meta-category, and someone or something
> ...
> > I don't think that the two you list are the only two options. To me
> > they read as the two sides of the binary assertions "we can depend
on
> > perfection from this part of the system." ...
> > When you soften (a) to require a high
> > probability of accuracy rather than perfection you end up with a
> > component you can build on.
>
> "High probability" is good enough for manual transactions - such as
the
> credit cards in a store... But when a small level of uncertainty
opens a
> possibility for *huge* exploits, the confidence level better as high
as
> possible.
That's exactly it, the greater the potential exposure the greater the
need for security. If I'm reading some random blog musing my needs are
different than when I am managing my bank account, for the former I
don't necessarily have any real worries whereas for the latter I do. If
I am enabled to choose between building trust with what may be my
bank's website from scratch or start already knowing the identity of
the authorized site operator I wouldn't need pause to consider which I
prefer. Would anyone? So given a CA who associates their livelyhood
with their effectiveness as an identity authenticator I would
definitely feel better about trusting them. Knowing that the CA has
operating insurance or significant assets helps too (that's kind of
like how banks decide who they trust when lending money). So directly
to your point - the higher the confidence level the better when dealing
with significant exposures and therefor the more rigourous the CA's
policies in authentication the better off the relying party is.
>
> Presenting the site's key fingerprint to the user as a matter of
course
> seems more and more like something that can not be avoided.
That's a basic assumption in PKI - you need to authenticate sites in a
way that's reproduceable. The thing that happened was that folks
decided they would try to bring more robustness by adding the
identification of legal identity to system. I don't believe that
putting a string of numbers in front of a user is part of a well
thought out approach.
As a practical aside consider that a "website" may choose to update
their keys for hygenic reasons and may operate in multiple locations.
Each instance would have it's own unique keys and certificates and
those would change after certifiate or key lifecycle operations (like
key update or certificate renewal). This means that if I am a customer
of 50 sites in a typical year and they do annual key updates - I'm
tracking a lot of data which perhaps you could optimize the software. I
suggest that outsourcing that tracking and making your imposition on
the user one that is automatic and natural for the user - like
recognizing names of companies - may be a better approach as the user
much of the complexity is removed from the user and placed on folks who
compete in the market. Trust and security are native concepts to people
while cryptography is not so if I were developing software that used
cryptography to help improve user security I would use natural
constructs to present security decisions and hide to the greatest
extent possible the underlying science.
Ram0502
> Ram0502 wrote:
>
> > That's an interesting suggestion, it provides the same kind of
> > authentication for HTTPS as the above does for secure email. If the
> > session is initiated by the CA this proves the ability to control
the
> > host at the specified location. I wouldn't give them my CC# but it
does
> > create a relationship. I wouldn't provide any sensitive information
to
> > them as they could be hard to track down if were facing fraud as
> > presumably I wouldn't know their identity.
>
> But what if the certificate is only used to protect passwords for
> webmail and doesn't need the ability to be found for fraud?
If I don't have any security requirements in my interactions with a
site because I have no risk in them than it seems I may not find it
very important to know who is on the other end of the session. Although
as part of managing access to my webmail account I may prefer to have
my password passed privately to the site, and for that to be useful I
need to know I'm at the right site though in this case I just need
consistency not a proper legal identity. Given a site that is careful
not to change DNS names, and careful to share their keys across all
machines that service it at all the locations they may have (Yahoo must
have multiple points of presence with racks of machines at each), and
the presence of some particular UI elements in web clients I don't need
a professional identity checker. These are non-trivial requirements on
the site operator but it would save them some money. I wouldn't be
surprised if there is room for innovation here but I wouldn't forgoe
all my other security concerns in favor of pursuing this functionality.
>
> Binary security can't deal with both situations simutaniously and
> adequately, it needs to indicate visually the level of security...
I couldn't agree more that visual feedback to the user is a good UI
mechanism. I'll start a thread with some ideas that have been bubbling
around my head - visual feedback plays prominently.
Duane
> key update or certificate renewal). This means that if I am a customer
Renewal doesn't usually effect the private key... Although multiple
servers with different private keys would be an issue... The thing is
while you're hiding the finger prints someone else is intercepting your
traffic with a different key and unless you dig into the SSL dialogs you
virtually can never tell if anyone is proxying your traffic or not...
C. D. Rok
> ...Trust and security are native concepts to people
> while cryptography is not so if I were developing software that used
> cryptography to help improve user security I would use natural
> constructs to present security decisions and hide to the greatest
> extent possible the underlying science.
That layer used to hide the science is a Petri dish on which the
expolits breed.
CD Rok
Ram0502
Duane wrote:
> Ram0502 wrote:
>
> > key update or certificate renewal). This means that if I am a
customer
>
> Renewal doesn't usually effect the private key
I agree that it doesn't have to be this way but I bet few people change
their keys very often, I suspect certificate renewal is about the only
time it happens. I know at least one public CA that requires key
changes at the first renewal past a certain key age.
>... Although multiple
> servers with different private keys would be an issue... The thing is
> while you're hiding the finger prints someone else is intercepting
your
> traffic with a different key and unless you dig into the SSL dialogs
you
> virtually can never tell if anyone is proxying your traffic or not...
I think you're saying that because the user isn't comparing key (or
cert.) finger prints that they don't know who they are actually
connected to. My expectation when I'm at home is that my browser will
show me the certificate details of the site *my* SSL session is
terminating at - which may be a proxy server. I'm pretty sure that's
the behavior of Moz., FF, and IE - am I wrong?
Ram0502
I agree. Thought it's not always the weak point. The RSA implementation
in NSS has never IIRC been found to be a failure point in the wild. I'm
not saying their perfect just that it's not worth attacking as it's not
a practical weakpoint. I think overall there are UI lackings that have
greater impact on web client security than the quality of the RSA or
SSL implementations in the NSS (or CAPI) stack do.
I'm not always convinced when dealing with car repair that I got an
accurate assesment or a fair price, I depend on reputations as reported
by people I know and journalists and my own experiences and instincts ;
I think this is the nature of the compromise we make when we decide to
pay others to do things for us.
Nelson B
> Nelson pointed out how bad email verification is, but what if that's all
> you can prove?
IMO, there are cert applications for which "low assurance" is adequate,
and there are those for which greater assurances are needed.
By way of example, signed code poses higher risk than signed email text,
and so the certs needed for code signing should have high assurance,
higher than may be required for email certs. SSL server certs are
somewhere in the middle. mozilla treats SSL server certs like code
signing certs for java script served over https, IINM, so SSL server
certs really should be issued on the basis of the same strong
authentication as is more commonly used for code signing cert.
If a CA decides that they are unwilling or unable to do anything
stronger than weak assurances, then IMO they should limit themselves
to issuing certs that require only low assurances.
Choosing to be a low-assurance CA is a legit choice, IMO, as long as
the low assurance CA doesn't then issue certs used in applications
that require high assurance.
--
Nelson B
Duane
> Choosing to be a low-assurance CA is a legit choice, IMO, as long as
> the low assurance CA doesn't then issue certs used in applications
> that require high assurance.
Is there something that can be done to add extra bits to the server
certs, atm when I see "Class 3" server certificates in the browser it's
purely informational, why not mark those certificates high trust with
bits in the nss libs and then have the chrome show this information,
maybe instead of a padlock open/closed, have a set of different icons
that show class 3 issued certs visually as being different then Class 2
or Class 1, at present CAcert only issues from the 1 root cert, but we
do issue different classes of certificates, at present the length of
time is the give away... 180 days = low trust, 720 days = high trust...
It's really a no brainier to take that 1 step further and issue them
under different root certs etc...
Again, binary security can't deal with this other then with
informational fields and they are more or less useless unless people
actually pay attention to them, which I doubt most people will... So
make it blatantly obvious for them, this is good for web mail, this is
good for credit cards, this is somewhere in the middle of them both...
Ram0502
Duane wrote:
> Nelson B wrote:
>
> > Choosing to be a low-assurance CA is a legit choice, IMO, as long
as
> > the low assurance CA doesn't then issue certs used in applications
> > that require high assurance.
>
> Is there something that can be done to add extra bits to the server
> certs, atm when I see "Class 3" server certificates in the browser
it's
> purely informational, why not mark those certificates high trust with
> bits in the nss libs and then have the chrome show this information,
> maybe instead of a padlock open/closed, have a set of different icons
> that show class
I agree, I would like to see an indication of the representation being
made.
> It's really a no brainier to take that 1 step further and issue them
> under different root certs etc...
That seems to be a defacto standard - public roots tend to be specified
with a policy (aka class).
Duane
> I agree, I would like to see an indication of the representation being
> made.
Even something simple like a red open lock for no encryption or class 0
(ie test cert with no verification), amber coloured lock for entry level
encryption, yellow for medium grade and green for high trust and a tank
for class 4/military grade certificates if people want to get carried
away with it... :)
As far as I am aware, most CAs only issue class 1 to 3 certificates only...
> That seems to be a defacto standard - public roots tend to be specified
> with a policy (aka class).
I meant for CAcert specifically to issue certs differently in future :)
Currently these is only 3 classes we issue from, email verified only
which to me doesn't seem good enough for credit card transactions, but
is fine for other things like web mail, smtp, pop3, imap etc, that is
simply for protecting passwords from people sniffing packets, which is
where CAcert kicked off and that was to protect wifi connections from
snooping, but not necessarily for protecting financial information.
The next class up is ID verified, by at least 2 others which we can
request copies of paper work from at any time. Dates of birth, names,
and govt issued photo IDs are checked in person etc...
Final class is those that want code signing, not only do they need at
least 2 others to verify their ID, but they need to have a copy of their
govt issued ID on file with CAcert...
Jean-Marc Desperrier
> [...]. mozilla treats SSL server certs like code
> signing certs for java script served over https, IINM, [...]
I really don't believe so.
Well, it shouldn't be very difficult to test. If it works, I'll be
amazed at how convenient it is, but it's just too convenient, they are
many SSL Site on which I go that I don't trust to access all what signed
js can access.
Nelson B
That is a policy of the application, not of NSS, BTW.
I objected to it for the reason that the subjects of SSL certs are
typically subjected to less authenticity checking than code signing
certs, and this policy allowed the lesser assurance certs to be used
as code signing certs. But the application folks seemed to want
added convenience more than the added security, IMO.
--
Nelson B
Nelson B
> Nelson B wrote:
>
>> Choosing to be a low-assurance CA is a legit choice, IMO, as long as
>> the low assurance CA doesn't then issue certs used in applications
>> that require high assurance.
>
>
> Is there something that can be done to add extra bits to the server
> certs,
I wish there were some way, but I don't know of any standard way to
represent the amount/strength of authenticity checking done by CAs
prior to issuance. There would have to be a new extension, or
alternatively it could be new info stored along with the cert in NSS's
cert store.
I think the X.509 folks never dreamed that there would exist
low-assurance CAs. They assumed all CAs would be high assurance.
They were thinking of an X.500 world model, in which directories and
CAs in each country would be governmentally regulated, and hence
held to high standards by their governments (as seems to be the case
in the EU, whence the X.500 folks came).
> when I see "Class 3" server certificates in the browser it's
> purely informational,
AFAIK, there's no uniform standard for classes. It might help a lot
if there were. WebTrust doesn't require classes. They test only that
a CA does what their CPS says, whatever that is.
> why not mark those certificates high trust with bits in the nss libs
> and then have the chrome show this information,
I think my predecessors (original designers of NSS) thought that
all SSL and code-signing CAs would be high assurance, and therefore
thought that the 3 trust bits (email, SSL, code signing) were enough
to distinguish (root CA) certs as to level of assurance.
--
Nelson B
Gervase Markham
> mozilla treats SSL server certs like code
> signing certs for java script served over https, IINM,
I don't think this is correct. JS served over HTTPS has exactly the same
abilities and restrictions as JS served over HTTP.
Gerv
Ram0502
Duane wrote:
> Ram0502 wrote:
>
> > I agree, I would like to see an indication of the representation
being
> > made.
>
> Even something simple like a red open lock for no encryption or class
0
> (ie test cert with no verification), amber coloured lock for entry
level
> encryption, yellow for medium grade and green for high trust and a
tank
> for class 4/military grade certificates if people want to get carried
> away with it... :)
I'd like to see an indication of what information the CA is prepared to
defend and to what extend they are making that assurance on identity
(e.g. we assure you this is IBM, NY, US and provide warranty as
follows) as well as some indication for signed software as to any
policy they may have arround appropriate use such as requireing up
front disclosure about what the software does.
Alex Wight
> I'd like to see an indication of what information the
> CA is prepared to defend and to what extend they are
> making that assurance on identity (e.g. we assure you
> this is IBM, NY, US and provide warranty as follows)
> as well as some indication for signed software as to
> any policy they may have arround appropriate use such
> as requireing up front disclosure about what the
> software does.
Of the CAs whose CP and CPS I've read, they all severely limit their
liability and provide little-to-no warranty at all. There may be some CAs
out there that do strongly warrant their identity proofing (note the use of
the word strongly), but they have no incentive to do so. Digital Signature
Trust Co. used to warrant it's SSL server certificates and also warranted
its TrustID client certificates for a significant amount of money, but from
what I've heard they no longer do so. My guess as to why would be because
they couldn't sell enough certificates (at whatever price the market would
bear) to pay for the insurance premiums that are necessitated by such a
warranty. It seems like people won't pay for warrantees unless the pain of
not having one becomes worth the cost a warranty incurs on the system.
I have yet to see *any* CA require disclosure by a customer applying for a
code signing cert about what the software does. If there was such a CA then
it wouldn't make sense for the CA to issue them a cert that could be used
over and over again to sign thousands of applications. It would make more
sense for the CA to simply sign the *one* application they required
disclosure for and never give a customer a private key/cert capable of
signing code that wasn't part of the CA's code review process.
-alex
Ram0502
> I have yet to see *any* CA require disclosure by a customer applying
for a
> code signing cert about what the software does. If there was such a
CA then
> it wouldn't make sense for the CA to issue them a cert that could be
used
> over and over again to sign thousands of applications. It would make
more
> sense for the CA to simply sign the *one* application they required
> disclosure for and never give a customer a private key/cert capable
of
> signing code that wasn't part of the CA's code review process.
VeriSign (and Thawte) have exactly that policy. It would certainly be
rough for a software publisher with lots of legitimate signed content
if they got theirt certificate revoked for a violation - but then they
are not as likely to do it. Having said that I still totally agree with
you - I think that is why some mobile phone platforms use an approach
where they can revoke individual signed packages in addition to or
instead of revoking the identity cert they were published by, I can dig
up a link if you want.
Ram0502
Nelson B wrote:
> Duane wrote:
> > Nelson B wrote:
> >
> >> Choosing to be a low-assurance CA is a legit choice, IMO, as long
as
> >> the low assurance CA doesn't then issue certs used in
applications
> >> that require high assurance.
> >
> >
> > Is there something that can be done to add extra bits to the
server
> > certs,
>
> I wish there were some way, but I don't know of any standard way to
> represent the amount/strength of authenticity checking done by CAs
> prior to issuance. There would have to be a new extension, or
> alternatively it could be new info stored along with the cert in
NSS's
> cert store.
I like that idea - I've started a thread that leverages it.
Duane
> I wish there were some way, but I don't know of any standard way to
> represent the amount/strength of authenticity checking done by CAs
> prior to issuance. There would have to be a new extension, or
> alternatively it could be new info stored along with the cert in NSS's
> cert store.
That's what I was hinting at... How hard would it be to do this without
breaking backward compatibility, yet in future the UI knowing about this
extension would be able to give the user more information?
> I think the X.509 folks never dreamed that there would exist
> low-assurance CAs. They assumed all CAs would be high assurance.
That's just naive... What other types of security, physical or other
wise uses a 1 size fits all policy?
> AFAIK, there's no uniform standard for classes. It might help a lot
> if there were. WebTrust doesn't require classes. They test only that
> a CA does what their CPS says, whatever that is.
Maybe this is something that needs to be part of what one of the other
guys were suggesting as part of their to CAs that wish to be included,
or remain in the browsers...
> I think my predecessors (original designers of NSS) thought that
> all SSL and code-signing CAs would be high assurance, and therefore
> thought that the 3 trust bits (email, SSL, code signing) were enough
> to distinguish (root CA) certs as to level of assurance.
Can we honestly say that is still the case, if not can it be addressed
some how in a sane manner to give the user more information on what
they're about to do, I guess this is similar to the debate over monetary
values etc...
This situation reminds me of the situation with road works in Sydney,
they tend to plan for the current needs instead of what will be needed
in 5 or 10 years time, so it's a constant game of catch up rather then
better planning to make everyone's lives a little easier.
Nelson Bolyard
> If HTTPS is the use for the cert, then as I suggested
> in some other random long rant today (!) we could
> always ask the domain owner to stick something in
> the HTTP page.
>
> Sort of like a little icon ad that people commonly do,
> you can see a couple of them in the below link. I
> think that makes a case that whoever stuck those
> in there has at least some control over the domain,
> for HTTP purposes.
Sorry for being thick here, but I don't understand what you're
suggesting. How does the content of an insecure web page
offer any proof of ownership that is stronger than email?
One falsified DNS record, or one bad line in your "hosts" file,
is all it takes to spoof any/all insecure web content from any
one site.
Sorry if I'm missing something obvious.
Jean-Marc Desperrier
> Nelson B wrote:
>> low-assurance CAs. They assumed all CAs would be high assurance.
>
> That's just naive... What other types of security, physical or other
> wise uses a 1 size fits all policy?
The correct X.509 mechanism to handle different level of assurance for
CA is by using certificate policies.
But this would require that implementations correctly support multiple
certificate policies, equivalence between policies, a normalized set of
policies to represent usual kind of assurance, and the validation of a
certification path against a policy.
In fact, the hardest point is to find out how this can be handled in
terms of user interface.
Nelson Bolyard
> Nelson B wrote:
>> I think the X.509 folks never dreamed that there would exist
>> low-assurance CAs. They assumed all CAs would be high assurance.
>
> That's just naive... What other types of security, physical or other
> wise uses a 1 size fits all policy?
Well, remember, X.509 is an outgrowth of X.500, which came from CCITT
(now known as ITU) the standards body of the European telephone companies,
all of which were (are?) state run or state sanctioned monopolies.
They thought *they* were going to be the operators of the X.500
directories and the X.509 CAs. I think the term "one size fits all
policy" describes the CCITT world of a few years ago pretty well.
>> I think my predecessors (original designers of NSS) thought that
>> all SSL and code-signing CAs would be high assurance, and therefore
>> thought that the 3 trust bits (email, SSL, code signing) were enough
>> to distinguish (root CA) certs as to level of assurance.
>
> Can we honestly say that is still the case,
I think we (er, MF) *could*, if MF was willing to require, in its CA cert
policy, that CAs for SSL and Code Signing must use a specified minimum
level of authentication in the issuance of those certs. But presently,
it seems the policy is willing to give any WebTrust-attested CA whatever
trust bits they request. So, at the moment, no, I cannot say it is still
the case.
> if not can it be addressed
> some how in a sane manner to give the user more information on what
> they're about to do, I guess this is similar to the debate over monetary
> values etc...
Yes. I very much wish we could get the UI czars for FF/TB engaged in
the discussions in n.p.m.security, but I'm not optimistic.
Ian G
> Jean-Marc Desperrier wrote:
>
>> In fact, the hardest point is to find out how this can be handled in
>> terms of user interface.
>
>
> I consider a lot of other things the UI has over come as being more
> difficult, either people don't understand the implications of binary
> security or they don't care, or a combination of both...
It's not quite that... It's based on the fact that
the secure browsing system has been in place
for a decade now and during that entire time,
people have grown used to the fact that it is
there and it works and it should be forgotten
as much as possible.
When it was put together, there was an enourmous
wave of commercial enthusiasm for something
that was loosely based on a threat that never
actually happened. If you want to get into that
I'd suggest reading some of Lynn Wheeler's
entertaining stories about the "good old days".
(Well, I find them entertaining ...)
Now, to all intents and purposes, this threat
was whalloped. Completely destroyed, and
this built up the notion that the system is
perfect, complete and invulnerable. Now,
there is so much 'belief' that the system is
like that, that even with today's top flight
security consultants, they have a very hard
time dealing with challenges to it. It is
simply outside their world view to think of
secure browsing as subject to any threat.
Meanwhile along comes phishing in 2003
or so and just waltzed past SSL as if it
wasn't there.
Shmoo showed what this was about. It drew
a straight line from dodgy domain to dodgy
cert to phish. It did it so clearly that it
exposed the secure browsing system for
what it is: a system that has never been
battle tested, and is full of contradictory
assumptions that leave open easy ways to
attack.
People are going to take some time to get to
grips with that.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Duane
> Duane wrote:
>
>> Ignoring the main interface, how hard/easy would it be to do something
>> like this as a plug-in instead?
>
>
>
> I guess that's what TrustBar does. Personally,
> I think that is non-optimal, I don't like the idea
> of plugins fiddling around with the keys and
> the various relationship structures. It raises
> hard questions about what happens when I
> write my new plugin to rewrite your relationships
> database in my favour.
My line of thinking here is it will get people accustomed to thinking
outside the binary security box and then go on to say "hey why isn't
this part of the main app, we deserve better then this", least that's my
hope at provoking this line of thinking :)
I think this is something that should be personal in nature, linking
back to a main database makes you still vulnerable to someone else's
opinion of what they think you should accept and no concept of over
rides etc...
Duane
> I think we (er, MF) *could*, if MF was willing to require, in its CA cert
> policy, that CAs for SSL and Code Signing must use a specified minimum
> level of authentication in the issuance of those certs. But presently,
> it seems the policy is willing to give any WebTrust-attested CA whatever
> trust bits they request. So, at the moment, no, I cannot say it is still
> the case.
To kill 2 birds with one stone I'll respond to Julian's posting as well...
Is it a safe assumption to make that generally while the class system is
mostly informational and that it is slightly standardised, or worst case
someone could make a judgement to sanitise the CAs slightly based on
their own CPS. I do realise this would require a fair bit of work for
someone, or maybe hassle the CAs for the information and their own
sanitising otherwise they get set to class one equivalency until they do
provide the information to the contrary.
Nelson, I'm guessing you'd be a good person to make lines in the sand as
to what is and what isn't acceptable, for example.
Perhaps the current class system isn't granular enough, and we need to
have classes 0 to 10, to better describe how much trust you should put
in each CA root certificate based on the policies they issue
certificates for.
Perhaps instead of using the existing class system and confusing things
more come up with a different naming scheme, like IDVL (IDentity
Verification Level), so this strictly relates to how well or how poorly
each CA does verification checking on each type of certificate issued
under what root certificate.
No verification = IDVL 0
email only verification = IDVL 1
faxed in verification (photo copied ID etc) = IDVL 2
web of trust like CAcert runs with in person meetings and formalised
documentation and policies = IDVL 3
public notary and original documents sent in or meet in person at the CA
office = IDVL 4
police ID check = IDVL 5
government/military background checking via police and other sources =
IDVL 6
Basically anything exceeding the above checks would be rounded down to
the closest variation, these are only example suggestions and they may
be too strict or too loose, I'll leave the specifics up to someone else
to comment on, however if we get some balance that everyone mostly
agrees on, even if it isn't implemented in the browser itself could it
be implemented as a plug-in? (more below)
> Yes. I very much wish we could get the UI czars for FF/TB engaged in
> the discussions in n.p.m.security, but I'm not optimistic.
Ignoring the main interface, how hard/easy would it be to do something
like this as a plug-in instead? Or maybe this is something someone can
make to incorporate both (Ian?) have a system of interacting with the
root certs, and based on finger print of the root certs have a stored
set of information (something like the above IDVL examples), after
judging the CPS (see above) and then have it show information on the
chrome etc...
If the main developers don't want to do it surely there is someone that
can? Obviously if a user wishes to bump a CA into a different category
they should be allowed to, the whole point of suggesting all this is to
give more decision making power to the user. Perhaps this plug-in could
also track certificate finger prints and do warnings if they change, or
allow the new finger print to also be added to the plug-in database as
also acceptable...
Ian G
> Ignoring the main interface, how hard/easy would it be to do something
> like this as a plug-in instead?
I guess that's what TrustBar does. Personally,
I think that is non-optimal, I don't like the idea
of plugins fiddling around with the keys and
the various relationship structures. It raises
hard questions about what happens when I
write my new plugin to rewrite your relationships
database in my favour.
Certainly, using the plugins to experiment
with different ways of handling the UI question
is a good idea. There is a plugin to do the
fingerprint thing, called SSLBar from memory,
and there are other plugins to also deal with
phishing in other novel ways: spoofstick (sp?)
does something simple, whereas the one by
Netcraft hooks back into its centralised DB.
So I would envisage a period of plugin
experimentation after which, some of the
best ideas get sucked into the core apps.
Just my thoughts...
Ian G
> Yes. I very much wish we could get the UI czars for FF/TB engaged in
> the discussions in n.p.m.security, but I'm not optimistic.
Of the following, which would you pick:
a. the problem will bubble along for a while,
b. the problem will get worse and worse,
perhaps as a result of phishing,
c. the problem will disappear of its own accord.
Reason I ask that is that if you pick the (depressing)
choice of b., then it might be time to start thinking
of escalating the issue.
I don't know how you'd do that ... almost all mature
organisations have a way of escalating issues, but
I don't know what it would be with Mozilla Foundation.
Duane
> In fact, the hardest point is to find out how this can be handled in
> terms of user interface.
I consider a lot of other things the UI has over come as being more
difficult, either people don't understand the implications of binary
security or they don't care, or a combination of both... PS see my other
reply as to you other points (my apologies for referring to you as
Julian, I should check next time :)
Ian G
> Ian G wrote:
>
>> If HTTPS is the use for the cert, then as I suggested
>> in some other random long rant today (!) we could
>> always ask the domain owner to stick something in
>> the HTTP page.
>>
>> Sort of like a little icon ad that people commonly do,
>> you can see a couple of them in the below link. I
>> think that makes a case that whoever stuck those
>> in there has at least some control over the domain,
>> for HTTP purposes.
>
>
> Sorry for being thick here, but I don't understand what you're
> suggesting. How does the content of an insecure web page
> offer any proof of ownership that is stronger than email?
Both are insecure only in absolute sense.
In reality, both are reasonably secure, with
known weaknesses. But those weaknesses
are not entirely correlated.
If both of these were requested, then an
attacker would have to change over the
domain name record of the email addresses,
as well as change over the DNS settings.
As the change for the DNS settings would
involve directing all (or most) DNS traffic
over a period that was hard to determine,
this would have a much greater chance of
being noticed.
> One falsified DNS record, or one bad line in your "hosts" file,
> is all it takes to spoof any/all insecure web content from any
> one site.
Right. But the web content is on a site
that is currently in use. And, the more
it is in use, the more it is going to be
noticed, so this scales nicely with the
importance of the check.
The reason the email trick works - I
guess - is because that email path is
never used.
Duane
> (I'm guessing you switched across to the Netcraft
> datanase here?)
Nope, but was reading you post about it...
> Right. But what if it worked? Linking back to
> a DB is more or less what OCSP tries to do, go
> back to a DB and see if a cert is still good.
I'm not saying it's a completely bad thing, in the case of CRL/OCSP this
is needed for other reasons, and the ones that issued it should have the
ability to control what happens later in response to breaches of
agreements (malware etc)
> All the Netcraft thing is doing is using their
> own database, and skipping the cert side
> altogether. It's the antithesis of suggestions
> made here (be Gervase) that all anti-phishing
> efforts should be concentrated in SSL.
And we both know how well things are working on that front... As I said
a centralised system isn't always a bad thing, but it depends on the
implementation and how much tracking actually occurs, I don't like the
ability to turn around and use my own statistics against me...
You went to xyz website so you must support/hate <insert favourite
group>, there is a limit to what should and shouldn't occur in these
situations and how much of the code is released to know how much?
Ian G
> My line of thinking here is it will get people accustomed to thinking
> outside the binary security box and then go on to say "hey why isn't
> this part of the main app, we deserve better then this", least that's
> my hope at provoking this line of thinking :)
(By all means I agree that the binary security
thing is something that has to be addressed
one way or another...)
> I think this is something that should be personal in nature, linking
> back to a main database makes you still vulnerable to someone else's
> opinion of what they think you should accept and no concept of over
> rides etc...
(I'm guessing you switched across to the Netcraft
datanase here?)
Right. But what if it worked? Linking back to
a DB is more or less what OCSP tries to do, go
back to a DB and see if a cert is still good.
All the Netcraft thing is doing is using their
own database, and skipping the cert side
altogether. It's the antithesis of suggestions
made here (be Gervase) that all anti-phishing
efforts should be concentrated in SSL.
iang
Frank Hecker
> AFAIK, there's no uniform standard for classes.
Correct AFAIK, although there are some sort-of conventions (e.g., "class
1" = minimal validation, e.g., via email, "class 4" = use of hardware
tokens). Although of course this "sort-of" standardization is exactly
what has plagued PKI from the very beginning (e.g., the proliferation of
similar but not identical certificate profiles).
> It might help a lot
> if there were. WebTrust doesn't require classes. They test only that
> a CA does what their CPS says, whatever that is.
The ETSI standards (TS 101 456 and 102 042) do define a reasonably
straightforward set of classes, although they don't the use the word
"classes" per se. (They refer to "certificate policies.)
Also, the Electronic Authentication Partnership does define a set of
standard classes in their "trust framework" working draft:
http://www.eapartnership.org/docs/Trust_Framework_0105.pdf
However... beyond the lack of standardization, what I find problematic
about all these documents is that they focus on levels of assurance in
isolation, independent of the contexts to which the assurance is
actually relevant. It's just rehashing the old PKI practice of focusing
on authentication of entity identity as the only issue, and not looking
at the actual real-world applications.
Frank
--
Frank Hecker
hec...@hecker.org
Frank Hecker
> I think we (er, MF) *could*, if MF was willing to require, in its CA cert
> policy, that CAs for SSL and Code Signing must use a specified minimum
> level of authentication in the issuance of those certs. But presently,
> it seems the policy is willing to give any WebTrust-attested CA whatever
> trust bits they request. So, at the moment, no, I cannot say it is still
> the case.
For the record, I would be willing to consider revising the draft CA
certificate policy to incorporate requirements on minimum assurance
levels for particular purposes. However...
1. I'd like more information on whether you and others want this simply
as a "good thing", or whether we have real evidence that this will
address a real problem, based on past evidence and future plausibility.
If this is mainly just a "good thing" then while I might agree that it's
a "good thing" as well, I don't necessarily want to enshrine it in
policy, at least right now.
2. I need proposed language for a future policy draft, and a consensus
behind that language; this by implication also means consensus on what
the minimum requirements should be for each type. If there is no such
consensus then I will postpone this issue to a future version of the policy.
3. I would like to see some investigative work done to determine how
this policy would affect "incumbent" CAs (i.e., CAs already in the list
prior to my taking on approving new ones) and "newly-approved" CAs
(i.e., CAs I've approved myself). Since part of the policy involves the
possibility of going back and re-considering CAs already on the list,
I'd like to know how this proposed change is going to affect things.
(For example, will we have to face a decision on kicking out a lot of
CAs, or at least restricting the "trust bits" we set for them?)
4. I would like clarity on how existing Mozilla/Firefox/Thunderbird/etc.
implementations may interact with such a policy. (For example, I think
you previously alluded to Mozilla implicity trusting JavaScript in some
context if it were downloaded from an SSL-enabled site.) I am reluctant
to implement a policy if the code itself negates its intent.
Alex Wight
> Nelson B wrote:
> > AFAIK, there's no uniform standard for classes.
> Correct AFAIK, although there are some sort-of conventions (e.g., "class
1" = minimal validation, e.g., via email, > "class 4" = use of hardware
tokens). Although of course this "sort-of" standardization is exactly what
has plagued > PKI from the very beginning (e.g., the proliferation of
similar but not identical certificate profiles).
In the Federal and State/Local Government PKI implementations there has been
and currently is a strong requirement for this type of certificate assurance
level. In at least 4 implementations that I'm aware of, they use the exact
same levels of certs (that also map to private key storage medium BTW):
Low Assurance - Identity verified via electronic means (email address,
databases), private key stored in software.
Medium Assurance - Identity verified using in-person methods (photo ID check
by either an RA or by a Notary Public), private key stored in software.
High Assurance - Identity verified using in-person methods (photo ID check),
private key stored in hardware (Smart Card or USB token).
They signify the assurance level by the CertificatePolicy OID, but
unfortunately, they all use a different set of 3 OIDs to represent
low/med/high. They then leave it up to the owners of a relying application
to enforce which policy level is acceptable for their particular
application. Seems like a logical fit for what we're talking about here,
except there needs to be a standard set of CP OIDs for the assurance levels,
and there needs to be checks and balances in the system to ensure that CAs
asserting the CP OID are really performing the appropriate levels of I&A
(identification & authentication).
-Alex
Nelson B
> Both are insecure only in absolute sense.
> In reality, both are reasonably secure,
There is typically a low probability of attack against either
of them if they are low value targets.
> with known weaknesses.
Namely, they fall apart under not-very-difficult attacks.
> But those weaknesses are not entirely correlated.
No?
> If both of these were requested, then an
> attacker would have to change over the
> domain name record of the email addresses,
> as well as change over the DNS settings.
Both MX records (which direct email routing) and A records
which return IP addresses for host names are DNS records.
It suffices to poison the resolver cache of a single victim's
computer to accomplish the attack on both.
> As the change for the DNS settings would
> involve directing all (or most) DNS traffic
> over a period that was hard to determine,
> this would have a much greater chance of
> being noticed.
Only the issuer's traffic need be directed.
>> One falsified DNS record, or one bad line in your "hosts" file,
>> is all it takes to spoof any/all insecure web content from any
>> one site.
> Right. But the web content is on a site
> that is currently in use. And, the more
> it is in use, the more it is going to be
> noticed, so this scales nicely with the
> importance of the check.
Noticed by whom?
You still haven't explained how web content is supposed to give
the issuer any more assurance about the party to whom an SSL
cert is about to be issued. I gather that you propose that
the issuer will look at the page that (supposedly) comes from the
requestor's server, and take assurance therefrom. If that is your
proposal, then only the resolver cache used by the issuer's
machine need ever be compromised by the attacker.
> The reason the email trick works - I
> guess - is because that email path is
> never used.
uh, no. It's because whatever email the issuer sends to the
intended recipient is intercepted by the attacker. The attacker
can click on any links, and use any passwords found in the mail
that was intended for the proper recipient, since the email
messages were not secured in any way.
--
Nelson B
Nelson B
> The correct X.509 mechanism to handle different level of assurance for
> CA is by using certificate policies.
I've read that claim before. Policy extensions contain OIDs that
identify policies. I have seen very very little in the way of
standarized policy OIDs. The US DOD has defined its own OIDs that
don't seem to me to have general applicability in other markets.
Seems to me that until there are a good number of standardized policy
OIDs that can be used by mutually independent CAs, policy extensions
will be just an idea.
Maybe I'm mistaken. If there's some large body of work on policy OID
definitions that has escaped my notice, please feel free to enlighten me.
> But this would require that implementations correctly support multiple
> certificate policies, equivalence between policies, a normalized set of
> policies to represent usual kind of assurance, and the validation of a
> certification path against a policy.
I think we're saying the same thing. Lack of universally accepted
policies (er, policy OIDs) is hold policy extensions back.
Even if NSS implemented policy extensions today, lack of policy
definition would make it pretty useless, IMO.
> In fact, the hardest point is to find out how this can be handled in
> terms of user interface.
I don't know how one would design *good* UI for policies while they
remain so abstract.
--
Nelson B
Nelson B
> I'd like to see an indication of what information the CA is prepared to
> defend and to what extend they are making that assurance on identity
> (e.g. we assure you this is IBM, NY, US and provide warranty as
> follows) as well as some indication for signed software as to any
> policy they may have arround appropriate use such as requireing up
> front disclosure about what the software does.
If I'm not mistaken, it takes the entire CPS to state all that info.
The "indication of what information" is the URL of the CA's CPS, IINM.
Some CPSes are hundreds of pages long.
Now, if we could get a few standardized "profiles" of CAs, e.g. a
standardized "high assurance" profile, and a standardized "low assurance"
profile, then perhaps a cert could include an extension that says
"this CA conforms to standardized CA profile number XXXX".
It seems to me that this idea of standardized profiles is essentially
what ETSI was trying to accomplish with their "Qualified Statements",
about which most participants in this group have had little good to say.
I'm not aware of any other efforts to standardize profiles.
--
Nelson B
Nelson B
>>I wish there were some way, but I don't know of any standard way to
>>represent the amount/strength of authenticity checking done by CAs
>>prior to issuance. There would have to be a new extension, or
>>alternatively it could be new info stored along with the cert in
>> NSS's cert store.
>
> I like that idea - I've started a thread that leverages it.
What thread is that? What is the subject of that thread?
--
Nelson B
Nelson B
> Is it a safe assumption to make
no. :)
> that [...] the class system is mostly informational
Today, each CA defines its own classes.
> and that it is slightly standardised,
It doesn't seem standardized at all.
IIRC, the first CA to have "classes" was Verisign. I think some other
CAs have followed Verisign's lead in the definition of classes, and
have defined their own classes based loosely on Verisign's definitions.
But I wouldn't say that makes any of the class definitions standardized.
If I'm mistaken, and there is some body of work from some standards body
that is attempting to standardize classes, someone please enlighten me.
> or worst case
> someone could make a judgement to sanitise the CAs slightly based on
> their own CPS.
That's the sticky wicket. Making a judgement. You'll recall it was
the prospect of mozilla having to make judgements about CAs that got
us all down this long CA policy path in the first place.
If I may attempt to summarize where that got us, mozilla got out of the
judgement business. It now relies on "qualified" and "independent"
third parties to make those judgements, based on any of a growing number :(
of sets of possible criteria for judgement.
Also, an important part of Mozilla's present policy is that it is based in
some large measure on what the CA says its own policies are. The third
parties exist only to confirm that it honors its own stated policies.
> I do realise this would require a fair bit of work for
> someone, or maybe hassle the CAs for the information and their own
> sanitising otherwise they get set to class one equivalency until they do
> provide the information to the contrary.
I think we'd have to do something similar to what we've done with the
rest of the policy issues. Perhaps mozilla's cert policy could require
the CAs to make some sort of self-identification of the "classes" of
assurance employed for each of their CA certs, and require that the
evaluators assess those claims.
> Perhaps instead of using the existing class system and confusing things
> more come up with a different naming scheme, like IDVL (IDentity
> Verification Level), so this strictly relates to how well or how poorly
> each CA does verification checking on each type of certificate issued
> under what root certificate.
>
> No verification = IDVL 0
> email only verification = IDVL 1
> faxed in verification (photo copied ID etc) = IDVL 2
> web of trust like CAcert runs with in person meetings and formalised
> documentation and policies = IDVL 3
> public notary and original documents sent in or meet in person at the CA
> office = IDVL 4
> police ID check = IDVL 5
> government/military background checking via police and other sources =
> IDVL 6
That's an interesting list. Here are a few observations about it.
1. It seems to deal only with verification of personal identity (e.g.
personal name), and not with organizational relationships. If a person
wanted a cert that include "O=Mozilla Foundation", how would you verify
that the person is indeed affiliated with that organization? A similar
question applies to DNSnames in SSL server certs. The binding of
personal names/identities to organizational ones seems particularly
challenging to do well, as Juarj Bednar pointed out.
2. I think the idea of "police ID check" doesn't work in all nations.
In the US, where we don't (yet) have national ID cards, the closest thing
we have to ubiquitous ID is our drivers' licenses. The police do not
issue drivers' licenses, and the police are not considered authoritative
with respect to the accuracy of the DLs.
>> Yes. I very much wish we could get the UI czars for FF/TB engaged in
>> the discussions in n.p.m.security, but I'm not optimistic.
>
> Ignoring the main interface, how hard/easy would it be to do something
> like this as a plug-in instead? [snip]
>
> If the main developers don't want to do it surely there is someone that
> can?
Seems plausible. Maybe the creators of trustbar?
Maybe we should be trying to recruit them to join the ranks of the
"main developers" (as you called them).
--
Nelson B
Nelson B
> Nelson B wrote:
>
>> mozilla treats SSL server certs like code
>> signing certs for java script served over https, IINM,
>
> I don't think this is correct. JS served over HTTPS has exactly the same
> abilities and restrictions as JS served over HTTP.
OK, I'm glad to hear that! Thanks for setting that issue straight.
--
Nelson B
Jean-Marc Desperrier
> Now, if we could get a few standardized "profiles" of CAs, e.g. a
> standardized "high assurance" profile, and a standardized "low assurance"
> profile, then perhaps a cert could include an extension that says
> "this CA conforms to standardized CA profile number XXXX".
RFC3280 : 4.2.1.5. Certificate Policies
The certificate policies extension contains a sequence of one or more
policy information terms, each of which consists of an object
identifier (OID) and optional qualifiers. [...]
In an end entity certificate, these policy information terms indicate
the policy under which the certificate has been issued and the
purposes for which the certificate may be used. In a CA certificate,
these policy information terms limit the set of policies for
certification paths which include this certificate.
Just normalize an OID for the "high assurance" profile and the
standardized "low assurance" profile, and include them in a multi-valued
Certificate Policies field. Everything is there for it to work like that.
If the certificate doesn't include the extension with the needed values,
it is possible to use an external source to add that knowledge(*), it's
just more complex to manage.
* Just like NSS currently uses external methods to handle the
SSL/client/code signing trusted info for CA certificates and doesn't
extract them from the certificate content.
Jean-Marc Desperrier
> I think we're saying the same thing. Lack of universally accepted
> policies (er, policy OIDs) is hold policy extensions back.
> Even if NSS implemented policy extensions today, lack of policy
> definition would make it pretty useless, IMO.
Chicken and Egg. But really, it needs to be implemented first, and then
it will be possible to do a small scale experiment to find what kind of
OID to use and what to represent with those OID.
One can use there arbitratry OID, and even map them them later to
normalized value via policy mapping, but if not enough is implemented,
it's not possible to experiment.
A problem is that if it ever begins to develop, it will probably end up
somewhat stepping on the extended key usage extension, I don't believe
the two uses are fully orthogonal.
Frank Hecker
> It seems to me that this idea of standardized profiles is essentially
> what ETSI was trying to accomplish with their "Qualified Statements",
> about which most participants in this group have had little good to say.
I'm sorry, I must have missed that discussion. What were the nature of
the objections to the ETSI work? Was this in reference to the standard
certificate policies defined in ETSI TS 101 456 and 102 042?
I personally don't have any objection to CAs adopting standardized
certificate policies (including standard policy OIDs), in fact I think
it would be a good thing. However in practice I think this is unlikely
to happen for various reasons, mainly because a) I don't think the
"vendors", i.e., the CAs and the various bodies like ETSI, ANSI X9, EAP,
etc.) are really motivated to cooperate on doing this, and b) I don't
think the "market" (i.e., CA customers and "relying parties") really
cares about this.
(Although one could argue that standardized cert policies would make
comparing CA offerings easier, and hence be a boon for cert buyers, I
don't think that would make an actual difference in practice because I
don't think cert buyers make buying decisions based primarily on CA
policies -- it's more "can this CA sell me a cert that will cause my
customers not to see warning dialogs?")
I also think that the ETSI classification of policies is a good attempt.
My only point is that you still need a standardized mapping of the
policies to particular types of certificate use (e.g., code signing,
S/MIME email, and SSL servers in our case).
Also, a point of clarification: In the context of TS 101 456 and 102 042
the word "qualified" when used in connection with certificate policies
has a specific meaning IIRC: it refers to cert policies that are legally
aligned with EU member state digital signature laws. That's why TS 102
242 defines "non-qualified" (my term, not theirs) versions of the
qualified policies defined in TS 101 456; the level of assurance is the
same for the policies that have both qualified and non-qualified
variants, but the legal implications are slightly different in terms of
how the certs would be treated under EU and national laws and directives.
> I'm not aware of any other efforts to standardize profiles.
Well, there's the EAP work I mentioned previously, but it is broader
than just certs, and IIRC does not define standard policy OIDs.
Gervase Markham
> 4. I would like clarity on how existing Mozilla/Firefox/Thunderbird/etc.
> implementations may interact with such a policy. (For example, I think
> you previously alluded to Mozilla implicity trusting JavaScript in some
> context if it were downloaded from an SSL-enabled site.) I am reluctant
> to implement a policy if the code itself negates its intent.
This example was based, AFAIAA, on a misunderstanding - Mozilla does not
treat JS served over HTTPS in any significantly different way to JS
served over HTTP.
Gerv
Ian G
>
> > with known weaknesses.
>
> Namely, they fall apart under not-very-difficult attacks.
Right. So take two not-very-difficult attacks
or preferably three if you can think of them,
and force the attacker to do all three. His
risks go up 10 fold each time. This is what
you'd call common or garden grade security.
> > But those weaknesses are not entirely correlated.
>
> No?
Not entirely, no. One's email, the other's
a web site.
>> If both of these were requested, then an
>> attacker would have to change over the
>> domain name record of the email addresses,
>> as well as change over the DNS settings.
>
>
> Both MX records (which direct email routing) and A records
> which return IP addresses for host names are DNS records.
> It suffices to poison the resolver cache of a single victim's
> computer to accomplish the attack on both.
Right, there are multiple ways of doing that.
>> As the change for the DNS settings would
>> involve directing all (or most) DNS traffic
>> over a period that was hard to determine,
>> this would have a much greater chance of
>> being noticed.
>
>
> Only the issuer's traffic need be directed.
That certainly makes it easier for the attacker
to pick off both, but bear in mind he still needs
to run a proxy or website or some such, so his
costs increase even then.
And, what I
would suggest is that the caring CA be aware
of this, and do a check from somewhere else.
use SSH and jump over to another box. This
can be done via either email or for browsing.
>> Right. But the web content is on a site
>> that is currently in use. And, the more
>> it is in use, the more it is going to be
>> noticed, so this scales nicely with the
>> importance of the check.
>
>
> Noticed by whom?
Anyone who's looking at his site. His customers,
his users, his girlfriend. The point is that this
isn't foolproof, but it raises the risks and costs
for the attacker.
> You still haven't explained how web content is supposed to give
> the issuer any more assurance about the party to whom an SSL
> cert is about to be issued.
It shows he has control of the web site. So
now he has control over the website *and*
the DNS records, he should presumably have
identified himself better than if he had
shown control over one factor.
> I gather that you propose that
> the issuer will look at the page that (supposedly) comes from the
> requestor's server, and take assurance therefrom. If that is your
> proposal, then only the resolver cache used by the issuer's
> machine need ever be compromised by the attacker.
That's a good point; see above for a bypass
to that.
>> The reason the email trick works - I
>> guess - is because that email path is
>> never used.
>
>
> uh, no. It's because whatever email the issuer sends to the
> intended recipient is intercepted by the attacker. The attacker
> can click on any links, and use any passwords found in the mail
> that was intended for the proper recipient, since the email
> messages were not secured in any way.
>
No, ok, let me spell it out. The reason the
attack on the email goes by undetected is
because the admin name in the DNS record
is not used for any other purpose. So any
other emails that would otherwise be stymied
are not going to help trigger detection.
Just so we're clear; what is being proposed
is several small barriers and nuisances that
make it tricky for a thief to easily make one
hack and get away with it. It's an economic
approach, it's how you deal with things when
they are low value, and you don't want to
spend any money.
Which is fine, because we are dealing with
the standard of using email to authenticate
here, we are not trying to compete with
hard paper Id forms.
J. Wren Hunt
Hash: SHA1
Nelson's parent post which started this thread uses the words "insecure
email" I took his use of the word 'insecure' as deliberate and
interpreted it as saying that 'secure' mail would be just fine. We're
dealing with certs, why not just encrypt? A legitimate owner would be in
possession of the keys whereas MITM style attacks would not.
Wren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iD8DBQFCE50+A/qR4Uok1vQRAqYeAKCW+9q9eep4aZk24/KswAMpWVXJXACgugTT
8ucFBf325Ye8zgy28UUs5zA=
=KVdj
-----END PGP SIGNATURE-----
Ian G
> Nelson's parent post which started this thread uses the words "insecure
> email" I took his use of the word 'insecure' as deliberate and
> interpreted it as saying that 'secure' mail would be just fine. We're
> dealing with certs, why not just encrypt? A legitimate owner would be in
> possession of the keys whereas MITM style attacks would not.
It would be nice if we could use thunderbird
to create the keys, create a self-signed cert,
and start using it. That wouldn't address the
identity problem, but we don't have an identity
problem when we are emailing, only an encryption
problem (and 99.9% of users are happy to take a
risk for 99.9% of email anyway). Most of us send
email to people we already know, unlike with
web browsing to remote ecommerce sites.
But, as anyone can create keys, an email that
is uncertified wouldn't really add anything to
determining if you have the right to a domain,
would it?
Ian G
> If the email in question is being used by the CA to verify ownership of
> the domain then yes, encryption would foil the attacker's ability to
> perform any related change predicated of course on an existing
> relationship between CA and its client. Or more simply, if you divert my
> unencrypted mail you may act on the information you receive and I will
> be none the wiser (at least in the short term). Divert my encrypted mail
> and neither of us can act; you can't because you can't decrypt and I
> because I wouldn't be aware of the now missing missive anyway.
Yes, but that's not the attack. The original problem
here - I think, correct please if wrong - was that I
being the bad guy decide to get a cert for your domain.
I do the natty DNS poisoning trick that Nelson spoke
of. I create a key and I send it to the CA. Then the
CA sends back an encrypted email to that key, I
decrypt it, and follow the instructions...
You the original domain owner never get involved...
Duane
> I do the natty DNS poisoning trick that Nelson spoke
> of. I create a key and I send it to the CA. Then the
> CA sends back an encrypted email to that key, I
> decrypt it, and follow the instructions...
If I'm not mistaken this is the original snake oil that was pushed, and
the only long term problem, is with email addresses/code signing as you
pointed out Ian because it's the path less trodden.
People usually notice websites acting strangely (shortly there after
complain about it) and not being what it appears to be, and while the
dns may be poisoned for a small section of the internet this won't be
the sum total of it and there is numerous simple ways of over coming it.
Namely probing name servers in far flung locations, it might be easy to
poison one caching name server or one persons PC, try doing it to 50 or
100 though.
High profile sites pay lots of money for this exact service to ensure
that major providers aren't involved (directly or indirectly via
automated processes) in the distribution of poisoned DNS information,
low profile sites being a small target usually have their DNS hi-jacked
at the registrar level more often then not, which in this case they have
bigger issues then someone getting false certs issued.
The only issue with Ian's suggestion about probing a website/screen
scraping then is for the domains people only use for email or what not
and don't run websites, or run internal sites that are password
protected from the outside world...
Personally I have a number of domains I bought purely for email reasons,
and while it's not impossible to get a temporary site up, will everyone
else be in the same boat? What about the cheap email hosting deals but
they don't come with a website?
Ian G
>The only issue with Ian's suggestion about probing a website/screen
>scraping then is for the domains people only use for email or what not
>and don't run websites, or run internal sites that are password
>protected from the outside world...
>
>
Ah, to clarify, I was sort of assuming they
wanted the cert for their website. If they
wanted the cert for email/code signing,
then that won't be so easy.
I'm not sure how to cover that.
Duane
> Duane wrote:
>
>> The only issue with Ian's suggestion about probing a website/screen
>> scraping then is for the domains people only use for email or what not
>> and don't run websites, or run internal sites that are password
>> protected from the outside world...
>>
>>
>
> Ah, to clarify, I was sort of assuming they
> wanted the cert for their website. If they
> wanted the cert for email/code signing,
> then that won't be so easy.
There was another point in there that I maybe didn't make clear either.
My primary constant use I use certificates for, is to protect my smtp
and imap sessions even though I don't use it for websites on the same
domain...
Duane
> Ah, to clarify, I was sort of assuming they
> wanted the cert for their website. If they
> wanted the cert for email/code signing,
> then that won't be so easy.
Actually someone else pointed out an issue with the idea of screen
scraping a website to prove domain control...
"There are usually much more people with content change rights on the
homepage than have administrative privileges on the server. The ability
for adding content to the page (that might be closely monitored by
others) is in no way equivalent to the ability to get an SSL cert for it
(that might get used on a fake host). It would be a really nice
privilege escalation."
Duane
> Ah, to clarify, I was sort of assuming they
> wanted the cert for their website. If they
> wanted the cert for email/code signing,
> then that won't be so easy.
More....
"Firstly we have to talk about where this piece of code has to be:
- Many websites run a guestbook that allowes to insert html.
- Some providers allow their users to run a private website at
www.domain.com/user or www.domain.com/~user.
- Some provider give users a subdomain like user.domain.com
- Some ISP don't allow you to access domain.com but only www.domain.com
Secondly we have to think about who might be allowed to change this
index page:
- Some WIKIs allow everyone to change their index page
- Some pages have a newsticker on their index page that can be
updated by normal users (e.g. www.fsi.uni-tuebingen.de)
- Websites are often run by a multimedia/design/... department
that has nothing to do with administration."
... and...
"Many websites run php/cgi/whatever scripts that are vulnerable to
code-injection, and would allow to put the cacert code wherever the
attacker likes to. phpBB comes to mind, and so many other
applications."
Ian G
>Ian G wrote:
>
>
>
>>Ah, to clarify, I was sort of assuming they
>>wanted the cert for their website. If they
>>wanted the cert for email/code signing,
>>then that won't be so easy.
>>
>>
>
>Actually someone else pointed out an issue with the idea of screen
>scraping a website to prove domain control...
>
>"There are usually much more people with content change rights on the
>homepage than have administrative privileges on the server. The ability
>for adding content to the page (that might be closely monitored by
>others) is in no way equivalent to the ability to get an SSL cert for it
>(that might get used on a fake host). It would be a really nice
>privilege escalation."
>
>
Right. That's an insider attack, or as pointed out, a
privilege escalation. But the same applies to domains,
and indeed, any check that can be done can be
subverted by an insider attack.
The strategy is to find multiple checks that are cheap
but have little correlation with each other. It doesn't
matter so much if there is an easy attack on the one,
as long as it is a nuisance to combine it with another.
Also, bear in mind, the more the combined attack
spreads more people, the more this indicates the
site shouldn't be using email-only-authenticated certs.
The intention is to secure a low value cert, not to make
it invulnerable.
Ian G
>"Firstly we have to talk about where this piece of code has to be:
>
> - Many websites run a guestbook that allowes to insert html.
> - Some providers allow their users to run a private website at
> www.domain.com/user or www.domain.com/~user.
> - Some provider give users a subdomain like user.domain.com
> - Some ISP don't allow you to access domain.com but only www.domain.com
>
>Secondly we have to think about who might be allowed to change this
>index page:
>
> - Some WIKIs allow everyone to change their index page
> - Some pages have a newsticker on their index page that can be
> updated by normal users (e.g. www.fsi.uni-tuebingen.de)
> - Websites are often run by a multimedia/design/... department
> that has nothing to do with administration."
>
>... and...
>
>"Many websites run php/cgi/whatever scripts that are vulnerable to
>code-injection, and would allow to put the cacert code wherever the
>attacker likes to. phpBB comes to mind, and so many other
>applications."
>
>
Good stuff. Remember, there are no absolutely
secure systems. Do not let the perfect be the
enemy of the good. If you want references, I can
supply...
Duane
> The intention is to secure a low value cert, not to make
> it invulnerable.
I suggested this and no matter what I replied with you seemed to think
it was impossible to do (as did Nelson for other reasons)