EV == DV?
Eddy Nigg
at Bugzilla. Not new, not surprising, but apparently somebody has to
make a point to change things.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Nelson Bolyard
> This issue also has been already discussed here and at some bug entries
> at Bugzilla. Not new, not surprising, but apparently somebody has to
> make a point to change things.
>
> http://www.eweek.com/c/a/Security/Security-Researchers-Exploit-Vulnerability-in-Handling-of-EV-SSL-Certificates/
I doubt this will change what you think (or hope) it will.
I'd sooner guess that this will result in the plug being pulled on some
DV issuers who do an inadequate job of checking what they put in their
certs.
The real issue here is not DV==EV, but rather is that trusted issuers
are issuing bogus certs, and with such certs, regardless of whether
they're EV or DV, it is possible to do much damage. It's in the interest
of users, and of vendors and CAs who DO care about security to see these
careless CAs be exposed and discredited with all due haste.
I think it's pretty disgusting that the "researchers" who got that bogus
cert are withholding the name of the CA from whom they got it. In the
long run, this will not have the desired effect on security. In the
short run, it keeps these guys in the limelight longer, which I'm sure
they like.
Eddy Nigg
> I doubt this will change what you think (or hope) it will.
>
We shall see :-)
> I'd sooner guess that this will result in the plug being pulled on some
> DV issuers who do an inadequate job of checking what they put in their
> certs.
>
Which is obviously a problem.
> I think it's pretty disgusting that the "researchers" who got that bogus
> cert are withholding the name of the CA from whom they got it. In the
> long run, this will not have the desired effect on security. In the
> short run, it keeps these guys in the limelight longer, which I'm sure
> they like.
>
Yeah! I still hope that we'll know what exactly was in that cert...also
the suspected content of the DN.
Ian G
> The real issue here is not DV==EV, but rather is that trusted issuers
> are issuing bogus certs, and with such certs, regardless of whether
> they're EV or DV, it is possible to do much damage. It's in the interest
> of users, and of vendors and CAs who DO care about security to see these
> careless CAs be exposed and discredited with all due haste.
Yes. Expose them and let them be shown for all to see. Why ever not?
> I think it's pretty disgusting that the "researchers" who got that bogus
> cert are withholding the name of the CA from whom they got it. In the
> long run, this will not have the desired effect on security. In the
> short run, it keeps these guys in the limelight longer, which I'm sure
> they like.
I agree. I also think it is pretty disgusting that Firefox doesn't show
the name of all CAs on the URL bar.
Once a name is out there, we have a brand. Once there is a brand, the
CAs have a reason to behave.
It doesn't get much simpler than that.
iang
Eddy Nigg
>
> I agree. I also think it is pretty disgusting that Firefox doesn't
> show the name of all CAs on the URL bar.
>
> Once a name is out there, we have a brand. Once there is a brand, the
> CAs have a reason to behave.
YES! I like branding! :-)
Ian G
> On 07/17/2009 12:13 AM, Ian G:
>>
>> I agree. I also think it is pretty disgusting that Firefox doesn't
>> show the name of all CAs on the URL bar.
>>
>> Once a name is out there, we have a brand. Once there is a brand, the
>> CAs have a reason to behave.
>
> YES! I like branding! :-)
a HISTORIC OPPORTUNITY!
Iang and Eddy in agreement ... don't hold back, move quickly :)
iang, in shock!
Eddy Nigg
>
> a HISTORIC OPPORTUNITY!
>
> Iang and Eddy in agreement ... don't hold back, move quickly :)
Naaahh...it could be worse...actually we aren't so far apart most of the
times, it just seems like that to bystanders ;-)
Kyle Hamilton
equivalent, because they're not. (they are equal here, but not
equivalent.)
-Kyle H
On Thu, Jul 16, 2009 at 3:23 PM, Ian G<ia...@iang.org> wrote:
> On 16/7/09 23:17, Eddy Nigg wrote:
>>
>> On 07/17/2009 12:13 AM, Ian G:
>>>
>>> I agree. I also think it is pretty disgusting that Firefox doesn't
>>> show the name of all CAs on the URL bar.
>>>
>>> Once a name is out there, we have a brand. Once there is a brand, the
>>> CAs have a reason to behave.
>>
>> YES! I like branding! :-)
>
>
> a HISTORIC OPPORTUNITY!
>
> Iang and Eddy in agreement ... don't hold back, move quickly :)
>
>
>
> iang, in shock!
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Jean-Marc Desperrier
> I, too, support branding. We need to stop treating all the CAs as
> equivalent, because they're not. (they are equal here, but not
> equivalent.)
I'm not against branding per se, but GUI space is limited and I'm not
sure the end user is interested about branding.
So it should be small and unobtrusive.
Ian G
I accept that. I'd be happy with the normal favicon style, with mouse
over info / click for more.
It's also terribly important to show this because it is the CA making
the claim. If not shown, the browser makes that claim, which means
Mozilla carries some liability.
iang
Eddy Nigg
> On 17/7/09 09:46, Jean-Marc Desperrier wrote:
>> Kyle Hamilton wrote:
>>> I, too, support branding. We need to stop treating all the CAs as
>>> equivalent, because they're not. (they are equal here, but not
>>> equivalent.)
>>
>> I'm not against branding per se, but GUI space is limited and I'm not
>> sure the end user is interested about branding.
>>
>> So it should be small and unobtrusive.
>
>
> I accept that. I'd be happy with the normal favicon style, with mouse
> over info / click for more.
Well, if you move over the blue or green area in the address bar of a
secured site, it does exactly that....but I thought you had some more
intrusive branding in mind :S
Varga Viktor
http://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-AttackExtSSL-SLIDES.pdf
http://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-AttackExtSSL-PAPER.pdf
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> _______________________________________________________________________
> _
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Eddy Nigg
> I know, that i was slow on this, but does anybody other checked the description of this attack?
>
> http://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-AttackExtSSL-SLIDES.pdf
> http://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-AttackExtSSL-PAPER.pdf
>
Most of us are aware here of it, it was also widely presented at the CAB
Forum. I suspect that this is the turf of Johnathan to decide if Firefox
should block "mixed" content or not.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Florian Weimer
> Most of us are aware here of it, it was also widely presented at the
> CAB Forum. I suspect that this is the turf of Johnathan to decide if
> Firefox should block "mixed" content or not.
You should also consider if "mixed" includes content secured with
certificates from different EV CAs. After all, the UI shows the CA
name, and the user has a reasonable expectation that it applies to the
whole content.
Varga Viktor
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
elképzelés
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Florian
> Weimer
> Sent: Wednesday, November 11, 2009 9:59 PM
> To: Eddy Nigg
> Cc: dev-secur...@lists.mozilla.org
> Subject: Re: EV == DV?
>
> * Eddy Nigg:
>
> > Most of us are aware here of it, it was also widely presented at the
> > CAB Forum. I suspect that this is the turf of Johnathan to decide if
> > Firefox should block "mixed" content or not.
>
> You should also consider if "mixed" includes content secured with
> certificates from different EV CAs. After all, the UI shows the CA
> name, and the user has a reasonable expectation that it applies to the
> whole content.
Gervase Markham
> You should also consider if "mixed" includes content secured with
> certificates from different EV CAs. After all, the UI shows the CA
> name, and the user has a reasonable expectation that it applies to the
> whole content.
Definitely not. At the moment, mixed doesn't even include an EV and DV
mix. But if it did, we would want to allow e.g. a site to use a FooCA EV
cert and their analytics company to use a BarCA EV cert. If we didn't
allow this, it would create some very undesirable network effects in the
CA cert market - a site would need to use the CA that its analytics
company was using.
Gerv
Eddy Nigg
Well, actually it's very undesirable to include third party scripts and
other content in an EV secured site - actually for any SSL secured site.
Are users made aware that third parties have the ability to listen to
their submitted data to site X by including third party Y and Z. This
practice should be really discouraged if not outright forbidden.
Ian G
Hmm. Good point. Sounds like a content policy issue? Which is outside
the bailiwick of the certificate's statement over the original domain?
Has there ever been a guarantee provided that the owner of a cert is
delivering HTTP in a certain way?
iang
Varga Viktor
The EV was positioned that it is more secure than the NV or DV (normal or domain validated).
You can solve the statistic, if you want internally too.
Its not a solution that because you are lazy to develop your own scripts, and want to use the google uhrin, to make the EV "unsecure"
If the EV is more secure, then should have more restrictions. :)
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Gervase
> Markham
> Sent: Thursday, November 12, 2009 12:53 PM
> To: dev-secur...@lists.mozilla.org
> Subject: Re: EV == DV?
>
Michael Ströder
> Well, actually it's very undesirable to include third party scripts and
> other content in an EV secured site - actually for any SSL secured site.
Amen.
Ciao, Michael.
Gervase Markham
> Well, actually it's very undesirable to include third party scripts and
> other content in an EV secured site - actually for any SSL secured site.
> Are users made aware that third parties have the ability to listen to
> their submitted data to site X by including third party Y and Z. This
> practice should be really discouraged if not outright forbidden.
I think a site owner with an EV certificate is responsible for the
actions of third parties whose content he chooses to include, whether
that third party is another distant part of his company, his web design
agency, a sub-contractor, or an analytics company.
Insofar as anything is impossible, telling sites that in order to use EV
they must not include any third-party content is basically impossible.
"No metrics? You must be kidding me..."
Gerv
Gervase Markham
> Its not a solution that because you are lazy to develop your own
> scripts, and want to use the google uhrin, to make the EV "unsecure"
You are really suggesting that to use EV, 10000 companies all have to
develop and host their own metrics infrastructure?
> If the EV is more secure, then should have more restrictions. :)
But the question is whether this particular restriction a) actually
increases security, and b) is practical.
Gerv
Varga Viktor
You have a log ont he server, you have the sessions ont he server, you can follow the whole user activity.
It's not a hard thing to implement a process to collect your users data inside your server, then send it out in a secure way to your analitics company.
Of-course, its more easier, to simply use an external script. You get your salary as IT assistant, but you should not do anything for it, simply buy a service from an external. (Typical Windows IT administrator behaviour. )
If the EV can communicate a DV/IV/NV, then that site is not more secure than a these.
Its like the level of http/https mixed content.
The EV handling can be remain its current state, but then the hype that it is more secure should be removed from the minds.
> You are really suggesting that to use EV, 10000 companies all have to
> develop and host their own metrics infrastructure?
Yes? :)
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Gervase
> Markham
> Sent: Friday, November 13, 2009 11:14 AM
> To: dev-secur...@lists.mozilla.org
> Subject: Re: EV == DV?
>
M.Hunstock
> Insofar as anything is impossible, telling sites that in order to use EV
> they must not include any third-party content is basically impossible.
You should separate between "third party implements something and puts
it on the EV site" and "some stuff is linked from third party sites".
The second one should IMHO be blocked from client software.
mh
Eddy Nigg
> On 12/11/09 17:52, Varga Viktor wrote:
>
>> Its not a solution that because you are lazy to develop your own
>> scripts, and want to use the google uhrin, to make the EV "unsecure"
>>
> You are really suggesting that to use EV, 10000 companies all have to
> develop and host their own metrics infrastructure?
>
Develop your own? Why? Aren't there scores of open and closed source
applications doing just that?
>> If the EV is more secure, then should have more restrictions. :)
>>
> But the question is whether this particular restriction a) actually
> increases security,
Yes, 100% positive. It was also pointed out by notorious white and grey
hats Zusman/Sotirov, that this will be exploited at some point. Then
what....?
I guess we are smart enough to recognize the problematic with it. If
not, lets assume that some others did....
> and b) is practical.
>
Certainly those which processed statistics before Google offered to
include it in their web sites will have or had it already. Besides that,
taking responsibility isn't always practical...heck, using SSL isn't
practical!
Ian G
I think we just had a long discussion where it was pointed out that the
cert has a domain name, and the primary thing that CAs want to do is
swear black & blue that this domain name is controlled/owned by whoever
is controlling / owning it. And if we don't have a domain name, then
we've got nothing to say, apparently.
And that's what EV does. It generally swears off any "security" claim
other than instantiating the above own/control question to the Nth degree.
From a business perspective this makes sense. The notion that a CA
goes into a business and says "this is how you have to develop your
content" isn't a money-winning proposition. Businesses won't take
anything like that from a straight CA, quite rightly.
From a liability point of view it's a non-starter, which is why EV is
written like it is.
(Yes, I've read the EV guidelines, in depth. My open question is, who
wrote it, and why did they write it like that? One word: liability.)
The marketing position / hype factor is *your problem* not EV's problem.
Of course, you are encouraged to believe that EV certs mean the site
is more secure. They have to sell EV certs. Of course. But you can't
take that to the bank. That is your perception, and the moment you rely
on it, more fool you.
iang
PS: quickly jotted notes, no time to make them easier right now.
On 13/11/2009 11:50, Varga Viktor wrote:
> It's not a hard thing, to implement a metrics software.
> You have a log ont he server, you have the sessions ont he server, you can follow the whole user activity.
> It's not a hard thing to implement a process to collect your users data inside your server, then send it out in a secure way to your analitics company.
>
> Of-course, its more easier, to simply use an external script. You get your salary as IT assistant, but you should not do anything for it, simply buy a service from an external. (Typical Windows IT administrator behaviour. )
>
> If the EV can communicate a DV/IV/NV, then that site is not more secure than a these.
> Its like the level of http/https mixed content.
>
> The EV handling can be remain its current state, but then the hype that it is more secure should be removed from the minds.
>
>> You are really suggesting that to use EV, 10000 companies all have to
>> develop and host their own metrics infrastructure?
>
> Yes? :)
>
>
> �dv�zlettel/Regards,
>
> Varga Viktor
> �zemeltet�si �s Vev�szolg�lati Vezet�
> IT Service and Customers Service Executive
> Netlock Kft.
>
>
>> -----Original Message-----
>> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
>> [mailto:dev-security-policy-
>> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Gervase
>> Markham
>> Sent: Friday, November 13, 2009 11:14 AM
>> To: dev-secur...@lists.mozilla.org
>> Subject: Re: EV == DV?
>>
Gervase Markham
> You should separate between "third party implements something and puts
> it on the EV site" and "some stuff is linked from third party sites".
> The second one should IMHO be blocked from client software.
What is the technical, detectable difference between the two situations
you give?
Gerv
Jean-Marc Desperrier
> It's not a hard thing, to implement a metrics software.
It is a *really* hard thing to implement one that *scales* to hundreds
of requests per seconds inside a farm of servers.
Mozilla had one, gave up and decided to use an external solution instead.
Eddy Nigg
I had a brief look at mozilla.com and also know about some requirements for proxies of Mozilla, it appears there is no third party content in Mozilla's sites. And supposed it's absolutely necessary, why aren't those third party providers at least using EV themselves?
M.Hunstock
> What is the technical, detectable difference between the two situations
> you give?
If there is none (and you ask as if you think that there is none), what
is the advantage of having stuff behind URLs with other domains?
mh
Gervase Markham
> If there is none (and you ask as if you think that there is none), what
> is the advantage of having stuff behind URLs with other domains?
I'm afraid I am completely failing to understand your point. You will
need to explain it slowly, carefully and in detail if you think it's
important that I understand it.
Gerv
M.Hunstock
> I'm afraid I am completely failing to understand your point. You will
> need to explain it slowly, carefully and in detail if you think it's
> important that I understand it.
I can't judge if it is important that you understand it ;)
My point is: if EV certificates are used (in browsers) to display the
famous "green address bar" with the name of the organization that holds
the EV cert (and browsers like Firefox do that), then this is done
because the user can see who he is "talking to". If the user thinks he
trusts the cert owner, he can go on using that site.
But if the browser is also talking to google-analytics.com,
bigmouthmarketing.com or anything else, it is expanding the user's trust
to someone else without asking or showing that.
This is done with DV certs all the time, and if every embedded resource
has an HTTPS URL no warning is displayed. But if this is done when an EV
cert is presented by the "main page" (and by the browser UI to the user)
then there is no benefit at all from using EV certs (except the money
the CA gets more). Instead, the user just feels more secure, but that's
wrong.
Just imagine an online banking website that puts the session ID into the
URL. Then the (for example) marketing company whose scripts were
included gets them as well. Is it understandable that I don't want a
third party besides me and my bank to be able to hijack my session? ;)
mh
Eddy Nigg
> My point is: if EV certificates are used (in browsers) to display the
> famous "green address bar" with the name of the organization that holds
> the EV cert (and browsers like Firefox do that), then this is done
> because the user can see who he is "talking to". If the user thinks he
> trusts the cert owner, he can go on using that site.
> But if the browser is also talking to google-analytics.com,
> bigmouthmarketing.com or anything else, it is expanding the user's trust
> to someone else without asking or showing that.
> This is done with DV certs all the time, and if every embedded resource
> has an HTTPS URL no warning is displayed. But if this is done when an EV
> cert is presented by the "main page" (and by the browser UI to the user)
> then there is no benefit at all from using EV certs (except the money
> the CA gets more). Instead, the user just feels more secure, but that's
> wrong.
>
I entirely agree with that.
> Just imagine an online banking website that puts the session ID into the
> URL. Then the (for example) marketing company whose scripts were
> included gets them as well. Is it understandable that I don't want a
> third party besides me and my bank to be able to hijack my session? ;)
>
Not only that, but it's very easy to also listen to user names,
passwords, credit cards and any other possible transactions with very
easy JavaScript'ing....for example third parties might know how much I
would have in the bank, to whom I make which transfers and so forth...
Luckily there is Ad-block, but what about the casual user not aware of it?
I think much better protection should be offered and third party content
should be dropped or the green bar show not be shown. And don't tell me
that someevsite.com can take on the responsibility for Google,
yieldmanager and friends.
Ian G
> My point is: if EV certificates are used (in browsers) to display the
> famous "green address bar" with the name of the organization that holds
> the EV cert (and browsers like Firefox do that), then this is done
> because the user can see who he is "talking to".
Yes, and it does this.
> If the user thinks he
> trusts the cert owner, he can go on using that site.
> But if the browser is also talking to google-analytics.com,
> bigmouthmarketing.com or anything else, it is expanding the user's trust
> to someone else without asking or showing that.
This is viewing the whole world through a technological lens and
ignoring the business. You can do that, but it won't mean much.
The claim is fairly clear: the user is connected to the named site.
That's it. That's true for the business view and for the technological
view.
Now consider what happens in a business. You go to your online bank and
ask for a loan (over an EV-claimed SSL connection if you like). The
online bank goes to the credit agency and asks for a report. It goes to
a bunch of other people, as well. Maybe it asks the police for a police
records check, or the town county for a property check. Let's suppose
that the bank is reporting all your requests to a marketing agency. Why
ever not?
Conclusion: just because you are talking to your bank doesn't mean the
bank is the only person in the conversation. Your bank outsources a lot
of stuff. In the old days it did it "backoffice" so you couldn't see it.
Technology effect now is that instead of the bank talking to some of
these people behind the bank -- so you can't see it -- the bank is now
presenting you with the recipe, so you can do the talking.
Technologists would say "this scales." The bank has simply moved the
recipe from its backoffice to the frontoffice and then to the client
office a.k.a. your browser.
Another way of saying it is this: you are talking to your bank. It
just tells you in that conversation that you should talk to
google-analytics. It told you to do this securely, with the green stamp
on it. No problem.
> This is done with DV certs all the time, and if every embedded resource
> has an HTTPS URL no warning is displayed. But if this is done when an EV
> cert is presented by the "main page" (and by the browser UI to the user)
> then there is no benefit at all from using EV certs (except the money
> the CA gets more). Instead, the user just feels more secure, but that's
> wrong.
There is a deliberate mismatch between what the certificate does, and
what people think the certificate does. CAs generally go out of their
way to limit the legal reality to something tractable like a single
claim of a point-to-point connection from you to a named party.
The PKI industry as a whole, and CAs of course, also go out of their way
to let users feel secure using certs. However, you would be
hard-pressed to find even an advertisement that states that the certs
make you secure. That's because they don't, and the CAs are careful not
to state it, but to let you imagine they state it. It's good for CAs.
So above, you have perceived it should be like this. It ain't.
> Just imagine an online banking website that puts the session ID into the
> URL. Then the (for example) marketing company whose scripts were
> included gets them as well. Is it understandable that I don't want a
> third party besides me and my bank to be able to hijack my session? ;)
It is entirely understandable ... it's just out of scope.
This is behind that comment that we sometimes hear that EV did nothing
new, it just defined the old system, the old point-to-point claim, to
the Nth degree.
An opportunity missed. Oh well, at least certs look pretty in green
this season.
iang
PS: for those who don't like the observation that this is all that EV
does -- document the old point-to-point thing -- it wasn't me that made
that observation, but I'm happy to take the bullets as the messenger :-)
M.Hunstock
> Technology effect now is that instead of the bank talking to some of
> these people behind the bank -- so you can't see it -- the bank is now
> presenting you with the recipe, so you can do the talking. Technologists
> would say "this scales." The bank has simply moved the recipe from its
> backoffice to the frontoffice and then to the client office a.k.a. your
> browser.
That's true, I would expect just this: further processing "behind" their
servers, but not in parallel by linking some other site. Why? Because if
I do it directly from my servers, I have control over things.
I really did _not_ want to force the bank to leave my data in their
house. I know they don't ;)
> Another way of saying it is this: you are talking to your bank. It
> just tells you in that conversation that you should talk to
> google-analytics. It told you to do this securely, with the green
> stamp on it. No problem.
But is the bank taking responsibility/liability for third party scripts?
They must be crazy if they do that.
> This is behind that comment that we sometimes hear that EV did nothing
> new, it just defined the old system, the old point-to-point claim, to
> the Nth degree.
>
> An opportunity missed. Oh well, at least certs look pretty in green
> this season.
ack
pki-me-harder ;)
There are some nice slides from a prof in New Zealand about that, but I
lost the URL...
mh
Jean-Marc Desperrier
> You go to your online bank and ask for a loan (over an EV-claimed SSL
> Let's suppose that the bank is reporting all your
> requests to a marketing agency. Why ever not?
And imagine this actually gets reported to the clients of the bank ?
Do you really imagine they won't be up in arms ?
This being said I'm sometimes amazed by the apathy of Americans when
private companies do things they'd never accept from their government ;-)
Gervase Markham
> My point is: if EV certificates are used (in browsers) to display the
> famous "green address bar" with the name of the organization that holds
> the EV cert (and browsers like Firefox do that), then this is done
> because the user can see who he is "talking to". If the user thinks he
> trusts the cert owner, he can go on using that site.
> But if the browser is also talking to google-analytics.com,
> bigmouthmarketing.com or anything else, it is expanding the user's trust
> to someone else without asking or showing that.
But I don't think trust works like that.
If you trust me with the keys to your house, you also implicitly trust
me not to lend the keys to someone evil, or to allow them to get in when
I get in. That's just part of what trust is. If I do let people into
your house with your keys, I'm responsible for their actions in your house.
In the same way, if a website chooses to trust foo-analytics.com, then
their services become part of its site. They are responsible for it, and
if your account gets hacked because foo-analytics.com gets hacked, then
the bank is still liable, not you. (They may try and sue
foo-analytics.com to retrieve some of that money, but that's between
them and foo-analytics.com).
> Just imagine an online banking website that puts the session ID into the
> URL. Then the (for example) marketing company whose scripts were
> included gets them as well. Is it understandable that I don't want a
> third party besides me and my bank to be able to hijack my session? ;)
Then you shouldn't trust or do business with that bank. There are lots
of ways to code a website insecurely without including third party
content. Forbidding third party content does not guarantee secure coding
practices.
Gerv
Eddy Nigg
> Then you shouldn't trust or do business with that bank. There are lots
> of ways to code a website insecurely without including third party
> content. Forbidding third party content does not guarantee secure
> coding practices.
But it mitigates. Besides that, it's not a mere security issue, it's
about deceiving the user - quite frankly. If a user sees that he's
connected to "PayPal, Inc." he doesn't expect to be also connected to
doubleclick.net and friends without his knowledge. I'm certainly not
expecting it and was surprised to learn that this was the case (because
I had Ad-Block, I never paid attention).
M.Hunstock
> In the same way, if a website chooses to trust foo-analytics.com, then
> their services become part of its site. They are responsible for it, and
> if your account gets hacked because foo-analytics.com gets hacked, then
> the bank is still liable, not you.
That's exactly the point, because
- I doubt that the bank will be liable or let's say I don't want to rely
on the belief that the bank will state itself liable
- first of all I would like to avoid this situation at all -> no third
party content, no liability discussion.
> Then you shouldn't trust or do business with that bank. There are lots
> of ways to code a website insecurely without including third party
> content. Forbidding third party content does not guarantee secure coding
> practices.
Of course, but relying on third party content doesn't make it better. If
they "buy" some code and place it on their own servers, then there is at
least some kind of control (no unannounced upgrades, API changes etc.
and the code can be reviewed before getting online).
The next thing, if the browser UI doesn't tell me that there is third
party content in the site (I do not insist on forbidding, if it is
clearly visible that third party content is used) then how should I
evaluate my trust on that webapp/organization?
greetz
mh
Ian G
> Gervase Markham schrieb:
>
>> In the same way, if a website chooses to trust foo-analytics.com, then
>> their services become part of its site. They are responsible for it, and
>> if your account gets hacked because foo-analytics.com gets hacked, then
>> the bank is still liable, not you.
>
> That's exactly the point, because
> - I doubt that the bank will be liable or let's say I don't want to rely
> on the belief that the bank will state itself liable
Now we're getting it :) It's about liability. And how is liability
organised? Through either law, custom, regulator or contract.
*Not through RFC, mozo policy, CPS, maillist gossip or user angst*. I
don't say this to be nasty, but to point to a loophole as big as the
Atlantic in thinking.
The contract you have with your bank should organise the liability when
using the website. Now, possibly the bank has tried its damnest to dump
the entire liability on you. The contract probably has lots of clauses
in small print that make you completely responsible (more in anglo
banks). That's because they can, and that's the current cycle of the
industry (e.g., there is no express law as yet like the credit card law
over online banking).
We are more or less in tune with the bank not being (much) liable. So,
understandably we are very unhappy with this liability dumping. If we
know about it.
Understandably, users look at the green thing and hope that this changes
things. But why should it? I would doubt that it changes it one iota,
almost certainly every seller of a green cert simply says that the full
liability for the business arrangement, and what passes over the pipe,
is between the subscriber and their customers.
Relying parties (those that enter RPAs, *not* customers of the bank)
will be given certain limited rights which don't really improve their
life. If I'm wrong, let us know, guys :) But that isn't triggered by
any bytes sent by the bank to you.
If we are agreed that the bank is not liable, it is an understandable
mistake that the cert provider might be liable for something. But they
have covered that 17 ways to sunday. They are liable for something, but
that something is very small. They are not liable for what the bank
tells you what to do (how can they be?) and unless there is something in
the Guidelines about HTML practices, I'd reckon you've got no claim.
(However, they are not going to tell you that. Any guesses why?)
> - first of all I would like to avoid this situation at all -> no third
> party content, no liability discussion.
This service is regrettably not on offer. You have the option of going
to another bank. Other than that, you can grumble to your politicians
about this.
(Looking at your domain name, I'd suggest that latter isn't worth your
time. Arguably, German banks are the most powerful in the world, and if
they want to do this, they will do it. That's because they have the
most powerful regulator ... in this case I think there might be some
instructions to the banks to share the liabilities. ask them)
>> Then you shouldn't trust or do business with that bank. There are lots
>> of ways to code a website insecurely without including third party
>> content. Forbidding third party content does not guarantee secure coding
>> practices.
>
> Of course, but relying on third party content doesn't make it better. If
> they "buy" some code and place it on their own servers, then there is at
> least some kind of control (no unannounced upgrades, API changes etc.
> and the code can be reviewed before getting online).
>
> The next thing, if the browser UI doesn't tell me that there is third
> party content in the site (I do not insist on forbidding, if it is
> clearly visible that third party content is used) then how should I
> evaluate my trust on that webapp/organization?
Evaluate it down. Change bank. What's the problem?
iang
Eddy Nigg
>> The next thing, if the browser UI doesn't tell me that there is third
>> party content in the site (I do not insist on forbidding, if it is
>> clearly visible that third party content is used) then how should I
>> evaluate my trust on that webapp/organization?
>
>
>
> Evaluate it down. Change bank. What's the problem?
>
Errrr....how should the casual user know? I bet nobody expects it
either...nor do most have the knowledge we have nor do they read the
site's page source...
The browser should indicate that in some form? Either by downgrading the
EV UI or by signaling it otherwise...
Ian G
> On 11/18/2009 07:47 PM, Ian G:
>>> The next thing, if the browser UI doesn't tell me that there is third
>>> party content in the site (I do not insist on forbidding, if it is
>>> clearly visible that third party content is used) then how should I
>>> evaluate my trust on that webapp/organization?
>>
>>
>>
>> Evaluate it down. Change bank. What's the problem?
>>
>
> Errrr....how should the casual user know? I bet nobody expects it
> either...nor do most have the knowledge we have nor do they read the
> site's page source...
This is indeed the logic that people and legislators and regulators
sometimes take, in that they reason that the banks are in the best place
to ensure the security of the system, so therefore they are the best
party to take on the liability (by law if necessary). The liability is
a stick to make them improve the security; so the reasoning goes.
Where this cozy concept goes south is:
* online banking is simply too new to "know this,"
* the banks don't agree,
* certs aren't a good handle for distributing liability, and
* apparently _the user_ is now in best position to ensure the
security of her computing platform. Which is where the bulk of the
problem lies.
Within the CA industry and the banking industry, I expect there to be
quite serious resistance...
> The browser should indicate that in some form? Either by downgrading the
> EV UI or by signaling it otherwise...
What is a matter of current fact, as far as I know, is that security
programming of the website has little to do with certificates.
Show me the refs, if I'm wrong...
It could well evolve in that direction, but best off to do this a bit
carefully and thoughtfully.
iang
Eddy Nigg
The browser should indicate that in some form? Either by downgrading the
EV UI or by signaling it otherwise...
What is a matter of current fact, as far as I know, is that security programming of the website has little to do with certificates.
I would have a bunch to say about web site and server security, but that's not our focus here, so I skip that part. Instead lets concentrate on PKI. Here the browser tells me:
You are connected to
DOMAIN.COM
which is run by
CORPORATE, INC.
Locality
State, US
Your connection to this web site is encrypted to prevent eavesdropping.
What it however doesn't say is:
You are also connected to
DOUBLECLICK.COM
TRACKER.COM
GOOGLE.COM
for which we have no further information. Actually you don't expect it so we better not tell you about it either. Your Firefox.
It could well evolve in that direction, but best off to do this a bit carefully and thoughtfully.
Ian G
> .... Here the browser tells me:
>
> You are connected to
> DOMAIN.COM
> which is run by
> CORPORATE, INC.
> Locality
> State, US
> Your connection to this web site is encrypted to prevent eavesdropping.
Sure.
> What it however doesn't say is:
>
> You are also connected to
> DOUBLECLICK.COM
> TRACKER.COM
> GOOGLE.COM
> for which we have no further information. Actually you don't expect
> it so we better not tell you about it either. Your Firefox.
Actually, it doesn't say that because it isn't the whole truth. What is
more the truth is this:
NOW you must connect to:
DOUBLECLICK.COM
TRACKER.COM
GOOGLE.COM
and as many other friends of your bank as we tell you to. Coz it's good
for you. Coz we like these guys. And we have a very nice relationship
with them.
And that is entirely plain in the message (HTML) that is sent to the
user over the protected (no eavesdropping!) channel.
>> It could well evolve in that direction, but best off to do this a bit
>> carefully and thoughtfully.
>
> Well...I thought about this a lot and came to the conclusion that we'd
> better not deceive the users...
Er... you *really* don't want to go there!
iang
Eddy Nigg
>> What it however doesn't say is:
>>
>> You are also connected to
>> DOUBLECLICK.COM
>> TRACKER.COM
>> GOOGLE.COM
>> for which we have no further information. Actually you don't expect
>> it so we better not tell you about it either. Your Firefox.
>
>
> Actually, it doesn't say that because it isn't the whole truth. What
> is more the truth is this:
>
>
> NOW you must connect to:
> DOUBLECLICK.COM
> TRACKER.COM
> GOOGLE.COM
> and as many other friends of your bank as we tell you to.
Well, due to the nature of HTML (you mention this just below), browsers
do that because that's what they used to do in plain text.
>
> And that is entirely plain in the message (HTML) that is sent to the
> user over the protected (no eavesdropping!) channel.
Right, just most don't know what to do whit that. It's like me showing
you some code and asking you where some pointer might by allocated in
memory... ;-)
>> Well...I thought about this a lot and came to the conclusion that we'd
>> better not deceive the users...
>
>
>
> Er... you *really* don't want to go there!
>
As you might know, _I_ have no problem with that...
Ian G
> Well, due to the nature of HTML (you mention this just below), browsers
> do that because that's what they used to do in plain text.
Yeah .. the browser shows a binary signal ("good") wrapped over about 30
years of technological and institutional development, including HTML.
Arguments about what that binary signal should or does or can "mean" do
and will roll on forever.
It is a decision that Mozilla and other browsers have made that the
end-user of secure browsing gets one and only one signal. Good, or not
good.
It's the ultimate hash function, it takes more data than anything else,
and gives you one bit in return.
(Recently broken by the EV thing, finally, and frequently broken at the
micro-user-level because of the scare warning resulting in click-thru,
and also the plaintext confusion, but in principle, the decision for
binary good-ness holding up.)
In such an arrangement, the only meaning worth anything is the one that
everyone can agree on. Say hello to "lowest common denominator."
Hence, no claims about the security of the website are likely.
(Which is why we had DVs. As a consequence of Mozilla decisions, the
same is likely to happen to EV. Lowest common denominator rules!)
>> And that is entirely plain in the message (HTML) that is sent to the
>> user over the protected (no eavesdropping!) channel.
>
> Right, just most don't know what to do whit that. It's like me showing
> you some code and asking you where some pointer might by allocated in
> memory... ;-)
right, or me showing Alice a 160 bit long number and asking her to sign
it. "Do I have to initial every digit, or can I just sign at the bottom
of the number?"
>>> Well...I thought about this a lot and came to the conclusion that we'd
>>> better not deceive the users...
>>
>>
>>
>> Er... you *really* don't want to go there!
>>
>
> As you might know, _I_ have no problem with that...
Oh! Perhaps we should then add some clause to the policy. How about:
"the offering presented to the end-user by CAs must be
fairly presented and non-deceptive?"
Do you think we'll get support for that?
iang
Gervase Markham
> What it however doesn't say is:
>
> You are also connected to
>
> DOUBLECLICK.COM
> TRACKER.COM
> GOOGLE.COM
>
> for which we have no further information.
Feel free to write an extension :-)
Gerv
Eddy Nigg
Waste of time. And you are missing the point...