Flowchart covering SSL checks, error states, dialogs

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Flowchart covering SSL checks, error states, dialogs

beltzner
Is there a document anywhere that describes how a certificate is
parsed, analysed, which checks and confirmations are done in which
order, and when it's kicked out with errors, which of those errors are
user facing, etc?

Basically something like:
http://www.w3.org/2006/WSC/wiki/NoteKDECertificateValidationErrors

thanks,
mike

--
/ mike beltzner / phenomenologist / mozilla corporation /
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Gervase Markham
beltzner wrote:
> Is there a document anywhere that describes how a certificate is
> parsed, analysed, which checks and confirmations are done in which
> order, and when it's kicked out with errors, which of those errors are
> user facing, etc?

Not to my knowledge. Such a thing would be fantastic!

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

beltzner
On 2/1/07, Gervase Markham <[hidden email]> wrote:
> Not to my knowledge. Such a thing would be fantastic!

What I was able to offer the W3C was:

http://www.w3.org/2006/WSC/wiki/NoteMozillaCertificateValidationErrors

But if someone could help me construct the workflow, that would be
great. Any takers?

cheers,
mike

--
/ mike beltzner / phenomenologist / mozilla corporation /
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Nelson Bolyard
In reply to this post by Gervase Markham
beltzner wrote:
> On 2/1/07, Gervase Markham <[hidden email]> wrote:
>> Not to my knowledge. Such a thing would be fantastic!
>
> What I was able to offer the W3C was:
>
> http://www.w3.org/2006/WSC/wiki/NoteMozillaCertificateValidationErrors
>
> But if someone could help me construct the workflow, that would be
> great. Any takers?

This seems like a worthy goal.

Mike, you're asking about NSS code.  The folks who work on that all hang
out in m.d.t.crypto.  Your question would get more answers there, I think.
So, I'm cross posting this to both groups.

The page above cites 6 things that can be wrong in a cert chain.
There are many MANY more than 6.  A full flow chart would be Quite
large.  So I'm curious to know what level of detail you want.

One could put a bunch of tests into a box that said "do a lot of tests"
to simplify the chart, but would that defeat your purposes?

We could also just list a bunch of tests without specifying any details,
e.g. "check that key usage and extended key usage permit the intended
use for which we want this cert."  without making each one a separate
decision point in the flow chart.

I'm not volunteering to make a pretty flow chart, but I can definitely
help fill in the text if someone else can do the artwork.

--
Nelson B
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

heikki
Nelson B wrote:

> beltzner wrote:
>> On 2/1/07, Gervase Markham <[hidden email]> wrote:
>>> Not to my knowledge. Such a thing would be fantastic!
>> What I was able to offer the W3C was:
>>
>> http://www.w3.org/2006/WSC/wiki/NoteMozillaCertificateValidationErrors
>>
>> But if someone could help me construct the workflow, that would be
>> great. Any takers?
>
> The page above cites 6 things that can be wrong in a cert chain.
> There are many MANY more than 6.  A full flow chart would be Quite
> large.  So I'm curious to know what level of detail you want.

I think we could start from the states that are visible to the user:

- works
- silent rejection of connection (is this even possible?)
- all different error dialogs, prompts or similar that get shown to user

Then, I'd give a high level, short description of the checks that can
lead to each of the different dialogs. That way all the checks would be
lumped to something like half a dozen (?) boxes in the flowchart.

--
  Heikki Toivonen
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Nelson Bolyard
Heikki Toivonen wrote:

> Nelson B wrote:
>> beltzner wrote:
>>> On 2/1/07, Gervase Markham <[hidden email]> wrote:
>>>> Not to my knowledge. Such a thing would be fantastic!
>>> What I was able to offer the W3C was:
>>>
>>> http://www.w3.org/2006/WSC/wiki/NoteMozillaCertificateValidationErrors
>>>
>>> But if someone could help me construct the workflow, that would be
>>> great. Any takers?
>> The page above cites 6 things that can be wrong in a cert chain.
>> There are many MANY more than 6.  A full flow chart would be Quite
>> large.  So I'm curious to know what level of detail you want.
>
> I think we could start from the states that are visible to the user:
>
> - works
> - silent rejection of connection (is this even possible?)
> - all different error dialogs, prompts or similar that get shown to user
>
> Then, I'd give a high level, short description of the checks that can
> lead to each of the different dialogs. That way all the checks would be
> lumped to something like half a dozen (?) boxes in the flowchart.

Are you looking for UI flow, or the actual tests that are done to determine
validity?  I was assuming the latter based on the flow chart that Mike cited
at http://www.w3.org/2006/WSC/wiki/NoteKDECertificateValidationErrors

NSS provides two function for cert chain validation.  One takes a cert and
an indicator of intended usage (e.g. SSL server auth, S/MIME signer, S/MIME
recipient, etc.) and returns a no/no-go result (and optionally details).
The second detects server name mismatches for valid SSL server certs (that
have passed the first test).

IIRC, PSM groups the various errors into 3 groups, and has a separate dialog
for each.  A cert that has multiple errors may cause 1, 2 or 3 error dialogs
to appear.  The page Mike cited above shows two of the 3 dialogs.  It does
not show the name mismatch dialog.  The 3 possible dialogs (IIRC) are:

1) Some cert not within its validity period (expired, or not yet valid),
2) All other errors that cause the cert to not be "valid" as defined by
   the PKI standards, including being revoked.
3) server name mismatch.

Of these, only the second group offers a "permanent" override.  The error
dialog for the second group does not identify the specific problem, but
only generically describes several common problems of that group.

There is a proposal to change PSM UI to have only a single error page for
ALL possible cert errors, so a user doesn't get faced with multiple
error pages/dialogs for the same site.  Bug 327181, see screen shots at
https://bugzilla.mozilla.org/attachment.cgi?id=212593 (details hidden)
https://bugzilla.mozilla.org/attachment.cgi?id=212595 (details shown)

There is another proposal that doesn't combine all errors into one page,
but for each error, the error page would describe the specific problem
in readable form (no negative or hexadecimal numbers).  Bug 107491,
See screen shot at https://bugzilla.mozilla.org/attachment.cgi?id=252831

These proposals are all now about a year old.  They were barred from
consideration for FF2.  Let's hope they will be considered for FF3.

One key goal of SSL-related error pages/dialogs MUST be to point the
user to the SERVER admin rather than bugzilla for help.  99+% of the
SSL errors are the fault of some server admin, and there is no fault
in FF to be fixed.  But our current dialogs practically beg users to
blame all problems on us.  That's gotta stop, unless one of the Mikes
wants to personally answer all the bugs and group questions about those
errors going forward.

--
Nelson B
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Dan Veditz
Nelson B wrote:
> These proposals are all now about a year old.  They were barred from
> consideration for FF2.  Let's hope they will be considered for FF3.

Redesigning the security UI is a "P1" for Firefox 3. Redoing the errors was
explicitly added as a line item when we went over the plan this week.

http://wiki.mozilla.org/Firefox3/Firefox_Requirements_Meetings/Security_and_Privacy
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Eddy Nigg (StartCom Ltd.)
Reading the page below, it almost seems that EV support (aka "the green
carrot") in Firefox is already a certain thing?

Dan Veditz wrote:
>
> Redesigning the security UI is a "P1" for Firefox 3. Redoing the errors was
> explicitly added as a line item when we went over the plan this week.
>
> http://wiki.mozilla.org/Firefox3/Firefox_Requirements_Meetings/Security_and_Privacy

--
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Phone:       +1.213.341.0390

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Daniel Veditz
In reply to this post by Dan Veditz
It's certainly not going to be a green bar, but if we can come up with
something decent isn't it worth being able to tell the difference between
"we know these identities were validated to a certain standard" vs. "these
identities may or may not have been validated to that standard"?

Eddy Nigg (StartCom Ltd.) wrote:

> Reading the page below, it almost seems that EV support (aka "the green
> carrot") in Firefox is already a certain thing?
>
> Dan Veditz wrote:
>>
>> Redesigning the security UI is a "P1" for Firefox 3. Redoing the
>> errors was
>> explicitly added as a line item when we went over the plan this week.
>>
>> http://wiki.mozilla.org/Firefox3/Firefox_Requirements_Meetings/Security_and_Privacy
>>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Eddy Nigg (StartCom Ltd.)
Hi Dan,

Dan Veditz wrote:
> It's certainly not going to be a green bar, but if we can come up with
> something decent isn't it worth being able to tell the difference between
> "we know these identities were validated to a certain standard" vs. "these
> identities may or may not have been validated to that standard"?
My question to your suggestion is, if we can't come up with something,
that would tell the user _any_ difference between _any_ certificate.
Which means, to display the user the most important information in a
convenient way, which could be perhaps the subject line and issuer. Also
it should contain additional information, such as perhaps the key size
and encryption algorithm used for the connection, if the page contains
unsecured content, if the CRL was checked and if the issuer is known
(e.g. trusted). "EV validation" could be one of those details as well...

Another question remains, what happens if tomorrow a different forum
invents a different standard? Are you going to support it? If not, why not?

And at last, to what extent the Mozilla Foundation should endorse and
follow the recommendations of what is basically an industry trade group
for commercial CAs? Since the CA/Browser forum is a closed forum, which
doesn't even allow membership to non-commercial or lesser established
CAs, makes it highly suspicious of its real goals! Openness is key for
the success of it and certainly something Mozilla should strife for!

Thank you for your time!

--
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Phone:       +1.213.341.0390

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Gervase Markham
In reply to this post by Daniel Veditz
Eddy Nigg (StartCom Ltd.) wrote:
> My question to your suggestion is, if we can't come up with something,
> that would tell the user _any_ difference between _any_ certificate.
> Which means, to display the user the most important information in a
> convenient way, which could be perhaps the subject line and issuer. Also
> it should contain additional information, such as perhaps the key size
> and encryption algorithm used for the connection, if the page contains
> unsecured content, if the CRL was checked and if the issuer is known
> (e.g. trusted). "EV validation" could be one of those details as well...

Eddy, if we are destined to forever disagree on this, so be it. But I
can tell you for absolute certain that we are _not_ going to put Firefox
users in a position of having to know and evaluate the relative
trustworthiness of (or practices of) 50 different CAs, and the relative
strengths of different encryption algorithms and key sizes, in order to
work out whether a particular site is (relatively) safe to do business with.

"Throw all the information at the user and let them make up their own
mind" is not going to be our UI strategy. So you may as well stop
lobbying for it to be. :-|

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Michael Lefevre
On 2007-02-05, Gervase Markham <[hidden email]> wrote:
[snip]
> "Throw all the information at the user and let them make up their own
> mind" is not going to be our UI strategy. So you may as well stop
> lobbying for it to be. :-|

Seems to me that your own point extends to EV though.  I can't see what
solution there is to having at least 3 levels - EV cert, non-EV cert, and
no cert (possibly broken into some cert but without known root, and no
cert at all).  Is the plan to say that anything without EV is unsafe for,
say, credit card details?  Or will people know that EV is safe, and other
secure sites may or may not be safe, but definitely aren't as safe as EV.
Say, for example, that paypal and ebay get EV, but amazon doesn't - is
the user then supposed to know that it's ok to put credit card details
into amazon without the indication, but they shouldn't trust something
claiming to be ebay without it?

I don't see how a simple on/off indication is going to work, unless it is
"on" for any and all sites that a "normal" user wants to give their
personal details to, which would involve lots of people going out and
spending a lot of money on upgrading to EV (and I can't imagine that
happening immediately, and if it doesn't reach some kind of tipping point,
then the remainder probably won't see a reason to bother).

--
Michael
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Gervase Markham
Michael Lefevre wrote:

> On 2007-02-05, Gervase Markham <[hidden email]> wrote:
> [snip]
>> "Throw all the information at the user and let them make up their own
>> mind" is not going to be our UI strategy. So you may as well stop
>> lobbying for it to be. :-|
>
> Seems to me that your own point extends to EV though.  I can't see what
> solution there is to having at least 3 levels - EV cert, non-EV cert, and
> no cert (possibly broken into some cert but without known root, and no
> cert at all).  

It may not be ideal, but what's the alternative - stop supporting non-EV
certs (i.e. 99.99% of certs today)?

There are valid roles for domain-control certs - for example, if I get a
Welcome pack from my ISP saying "Get your secure webmail at
https://webmail.isp.net", then they doesn't need anything more than a
domain control cert.

> I don't see how a simple on/off indication is going to work, unless it is
> "on" for any and all sites that a "normal" user wants to give their
> personal details to,

"Personal details"? I give out personal details over plain HTTP all the
time. Is that really what you meant?

> which would involve lots of people going out and
> spending a lot of money on upgrading to EV (and I can't imagine that
> happening immediately, and if it doesn't reach some kind of tipping point,
> then the remainder probably won't see a reason to bother).

EV's success is certainly not guaranteed. But if 200 Paypal customers
have their account details stolen every day, and this becomes 150
because the other 50 IE 7 users go "no green bar - I won't enter my
password" then that's obviously worth it for Paypal.

It doesn't have to solve the problem completely to be worth doing, and
it doesn't have to be used by other sites to be valuable for your site.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Michael Lefevre
On 2007-02-06, Gervase Markham <[hidden email]> wrote:
> Michael Lefevre wrote:
[snip]
>> I don't see how a simple on/off indication is going to work, unless it is
>> "on" for any and all sites that a "normal" user wants to give their
>> personal details to,
>
> "Personal details"? I give out personal details over plain HTTP all the
> time. Is that really what you meant?

No - I was trying to generalise. I meant passwords for bank accounts,
credit card details and other stuff that that people really want to ensure
go to only the people they are intending to give them to.

> EV's success is certainly not guaranteed. But if 200 Paypal customers
> have their account details stolen every day, and this becomes 150
> because the other 50 IE 7 users go "no green bar - I won't enter my
> password" then that's obviously worth it for Paypal.
>
> It doesn't have to solve the problem completely to be worth doing,

I guess not, but it would be nice if it could :)

> and it doesn't have to be used by other sites to be valuable for your
> site.

No, but that would also help. If those 50 users recognise the green bar is
missing for Paypal, that's good. If 30 of them do their banking with
Anybank, who don't get EV, and Anybank says "it's ok to use our site
without the green bar", then maybe next time they are at Paypal, they will
forget that it's one of the sites that should have the green bar rather
than one of the sites that doesn't. Multiply that by lots of sites, and
people won't remember which have the green bar and which don't, and then
it's maybe only preventing 2 of those Paypal accounts getting stolen each
day, and at that point I'd wonder whether it is worth doing (in general,
not just for Paypal).

--
Michael
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Eddy Nigg (StartCom Ltd.)
In reply to this post by Gervase Markham
Hi Gervase,

*Please read this mail carefully!*

Gervase Markham wrote:
> There are valid roles for domain-control certs - for example, if I get
> a Welcome pack from my ISP saying "Get your secure webmail at
> https://webmail.isp.net", then they doesn't need anything more than a
> domain control cert.
Obviously there is a need for all kinds of certification as you
indicated here and it doesn't make "domain validated" or "reasonable
validated" or "extended validated", bad, better or good. Domain
validated certificates are excellent for the intended purpose....For
your web mail, control panel, forum and whatnot they are green as in EV ;-)

For small purchases at some online shop (lets say up to 100 $ per
purchase), reasonable validation might be in my opinion sufficient. It
also means, that you most likely will not start procedures to sue the
other party - so it's an option and you could. However there is a risk
and it's a risk many of you are willing to take (almost daily). Similar
risks exist when making a purchase in a foreign town, foreign country,
catalog purchase etc. or by simply ordering a pizza by phone...

But when accessing your bank account, you want be 100% sure, that only
your bank can have a certificate for its domain name and therefore your
bank most likely validated extensive and thorough. But since your
relationship with your bank happened out of the scope of the Internet
and you most likely visited a branch of the bank, there is no problem
with trust in relation to the web site (and with the associated
certificate). You simply know, that you arrived at the correct address
and it's safe to exchange information with your bank.

This is what certificates are mainly good for and I believe a solution
for other web sites which need to build up trust with its potential
customers is out of the scope of SSL certification. A different forum
and/or organization could provide such a solution perhaps and that's why
I also believe, that the approach the EV/Browser forum is taking, _is
wrong_, because it pretends and gives to the customer an illusion of
being trustworthy and safe. It's not! It could even backfire at some point!

However the problem is, how to present this in the UI, since content
can't be judged by the browser and yes, I believe the user must learn to
make decisions. My stance is, to help the user as much as possible to
make the right decision, and I offered one solution. There might be
other and better ideas perhaps...

However pretending that EV is the best thing since sliced bred and it
must be supported and implemented the way the CAs would like to have it,
because it will solve all problems on the Internet and beyond, is a
mistake...
>
> EV's success is certainly not guaranteed. But if 200 Paypal customers
> have their account details stolen every day, and this becomes 150
> because the other 50 IE 7 users go "no green bar - I won't enter my
> password" then that's obviously worth it for Paypal.
Two comments here:

First: Sites like Paypal, eBay and Amazon are unique and there aren't
that many actually. For this sites one might look for a different
solution perhaps. However it must be very clear, that businesses
operating sites in that scale and size, are and must be aware of the
risks they are taking! They must be prepared to defend themselves
against attacks and must be willing to protect their customers - even if
this means to reimburse a customer should he have fallen victim! It is
first and foremost the risk and responsibility of the operators of this
web sites! They are conducting their business they way they want to do
it and nobody forced them into this. When operating such a online
business, one has to calculate also the risks involved and be prepared
accordingly. Except that, I believe, that these site operators are
insured accordingly and know about all this very well!

Therefore I believe, that we (Browser vendors and CAs) are not, and
should not, be the front line defense of this handful of web sites! It's
perhaps not even in our interest to do this...why should we? These web
site operators should learn how to defend themselves and their
customers. Technology exists or can be invented - for example
authentication procedures which are unique to their site...Many
different ideas come to my mind here...

But the core question remains: Why should Mozilla take responsibility of
a business which does not even belong to Mozilla?!!! It's _their_
business, _their_ profits and _their_ responsibility! Let them find
_their_ own solution for _their_ own problem! These are huge enterprises
which have the resources and possibilities to find their own
solutions...by using simple user/pass pairs one might ask, if they are
putting their own customers at risk on purpose?! In my opinion this
borders on gross negligent!

Secondly, it seems to me, that the interested CAs in the CA/Browser
forum simply found reasons and an easy way in order to justify the
selling of over-priced digital certification by whining about pishing
attacks on eBay and Paypal. But by introducing special color schemes at
the browsers, smaller businesses will be more and more under pressure to
purchase the same, otherwise he might loose business...and all this on
the pretense, that EV is more trustworthy....
>
> It doesn't have to solve the problem completely to be worth doing, and
> it doesn't have to be used by other sites to be valuable for your site.
>

--
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Phone:       +1.213.341.0390

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Gervase Markham
In reply to this post by Michael Lefevre
Michael Lefevre wrote:

> No, but that would also help. If those 50 users recognise the green bar is
> missing for Paypal, that's good. If 30 of them do their banking with
> Anybank, who don't get EV, and Anybank says "it's ok to use our site
> without the green bar", then maybe next time they are at Paypal, they will
> forget that it's one of the sites that should have the green bar rather
> than one of the sites that doesn't. Multiply that by lots of sites, and
> people won't remember which have the green bar and which don't, and then
> it's maybe only preventing 2 of those Paypal accounts getting stolen each
> day, and at that point I'd wonder whether it is worth doing (in general,
> not just for Paypal).

It's certainly true that it's more valuable for each user if more sites
use it; there's a network effect. But I suspect average users only have
two or three financial sites they use regularly, if that. (Paypal, eBay
and their bank.) And I strongly suspect Paypal, eBay and the US banks
are going to be first in line for EV.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Gervase Markham
In reply to this post by Gervase Markham
Eddy Nigg (StartCom Ltd.) wrote:
> But the core question remains: Why should Mozilla take responsibility of
> a business which does not even belong to Mozilla?!!!

Because part of our business is to take people where they want to go,
but also keep them away from where they should not be - even if they
accidentally asked to go there. We take responsibility for helping our
users be safe, so far as we can, because that's a browser's role in 2007.

> It's _their_
> business, _their_ profits and _their_ responsibility! Let them find
> _their_ own solution for _their_ own problem!

They can't produce a solution without underlying security primitives in
the browser.

This is similar to the problem of trying to provide secure divisions
between users in a software product if the OS has no underlying concept
of different users (e.g. Windows 95). It just can't be done if the base
isn't there.

Still, I'm not sure what you are arguing. Should we rip out SSL support
altogether? After all, that would leave the field free for them to find
their own solution to their own problem...

> Secondly, it seems to me, that the interested CAs in the CA/Browser
> forum simply found reasons and an easy way in order to justify the
> selling of over-priced digital certification by whining about pishing
> attacks on eBay and Paypal.

If they are over-priced, then that's a business opportunity for you.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Eddy Nigg (StartCom Ltd.)
Gervase Markham wrote:
>
> Because part of our business is to take people where they want to go,
> but also keep them away from where they should not be - even if they
> accidentally asked to go there. We take responsibility for helping our
> users be safe, so far as we can, because that's a browser's role in 2007.
Yes, in that respect there are some nice advances and tools which help
to prevent pishing attacks exist for a while now...
>> It's _their_ business, _their_ profits and _their_ responsibility!
>> Let them find _their_ own solution for _their_ own problem!
>
> They can't produce a solution without underlying security primitives
> in the browser.
Right! However the browser provides this primitives for years already!
It is absolutely possible to find and provide better protection to users
of the web sites in question *without* the user or business having a
negative impact. This is true for years and this is a case I could
prove! The pishing problem exists already a long time and nothing or not
much has been done in that respect by the operators of these web sites
themselves! They still use simple user/pass pairs...and still put their
own customers on risk! Where is their own responsibility? This is true
with and without EV, with and without whatever-colored address bar!

I could get more into details here, but I spare you that ;-). But the
obvious is, that the very operators of the sites in question have the
solution to the problem much closer at hand than anybody else! Whining
that the Internet isn't secure or that browsers take the users to where
the want to go (even by mistake) is simply too cheap...and a bad
argument in favor of EV.

Please note, that that everything I said here is my personal opinion and
doesn't have to be necessary that of StartCom!
>
> Still, I'm not sure what you are arguing. Should we rip out SSL
> support altogether? After all, that would leave the field free for
> them to find their own solution to their own problem...
Digital certification is about encryption and identification on top of
it...Identify a web site and its owner! This is what it does, not more
and not less, even if you would paint the address bar dark blue or pink
or purple, it's still the same....The solution to pishing is somewhere
else, since it must prevent the user from making mistakes - something
which must be solved by the affected parties! Judging from the pishing
mails I receive, we are talking about a handful of web sites after all...

>> to justify the selling of over-priced digital certification
>
> If they are over-priced, then that's a business opportunity for you.
You must have some insider information, do you ;-)


--
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Phone:       +1.213.341.0390

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Gervase Markham
In reply to this post by Gervase Markham
Eddy Nigg (StartCom Ltd.) wrote:
> I could get more into details here, but I spare you that ;-). But the
> obvious is, that the very operators of the sites in question have the
> solution to the problem much closer at hand than anybody else!

Really? Perhaps you could suggest it, if it's so easy.

People thought that having the site display an image the user had to
recognise was one way - but a recent study shows that this doesn't work
either. I'm sure site operators are trying to find ways to improve
security as well, but they are having great difficulty, just as we are.

BTW, Eddy, it's spelt "phishing", with an H. :-)

>>> to justify the selling of over-priced digital certification
>>
>> If they are over-priced, then that's a business opportunity for you.
> You must have some insider information, do you ;-)

No. I just want you to stop asserting that EV certs are overpriced
unless you have some evidence that they are. And if you do, you should
go into business against them with a cheaper offering and clean up in
the market.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Flowchart covering SSL checks, error states, dialogs

Eddy Nigg (StartCom Ltd.)
Gervase Markham wrote:
>
> Really? Perhaps you could suggest it, if it's so easy.
No problem! We'd be glad to provide a workable and effective solution,
should any web site operator contact us and request it. However I doubt
that we are that much smarter than the developers of their sites....
>
> People thought that having the site display an image the user had to
> recognise was one way - but a recent study shows that this doesn't
> work either.
No, this is absolutely not what I meant, wrong way...
> I'm sure site operators are trying to find ways to improve security as
> well, but they are having great difficulty, just as we are.
I don't believe that...But as I indicated previously, the solution is
not in *your* hands, but in *theirs*. You build a browser, not web sites
and the security and authorization procedures of them. The browser
already provides all necessary primitives as you called it...There is
nothing else to do for you, except what you already provide, period!


--
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Phone:       +1.213.341.0390

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

smime.p7s (9K) Download Attachment