Re: A mighty fortress is our PKI

2010-07-27 Thread Chris Palmer
Perry E. Metzger writes:

 All major browsers already trust CAs that have virtually no security to
 speak of,

...and trust any of those CAs on any (TCP) connection in the (web app)
session. Even if your first connection was authenticated by the right CA,
the second one may not be. Zusmann and Sotirov suggested SSL pinning (like
DNS pinning, in which the browser caches the DNS response for the rest of
the browser process' lifetime), but as far as I know browsers haven't
implemented the feature.

A presentation I've given at a few security gatherings may be of interest. I
cover some specific security, UI/UX, and policy problems, as well as some
general observations about incentives and barriers to improvement. Our
overall recommendation is to emulate the success of SSH, but in a browser-y,
gentle-compliance-with-the-status-quo-where-safe way.

https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs

Eckersley's and Burns' presentation at Defcon (coming right up) will present
their findings from a global survey of certs presented by hosts listening on
port 443. Their results are disturbing.

Ivan Ristic is also presenting his results of a survey at Black Hat on the
29th. I don't know anything about his findings.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Chris Palmer
Paul Tiemann writes:

 Since this is a certificate we (DigiCert) have issued, I'm trying to
 understand if there is a vulnerability here that's more apparent to others
 than to me,

If an attacker can steal the cert by any means, perhaps by means particular
to one of the hosted sites, he can now forge the identities of the 100+
sites. It gives the attack a multiplier. (It appears 100+ is not even the
largest number of entities in a single cert.) Potential attacks:

* Attack the server (e.g. buffer overflow in FooHTTPD or some other bug in
a web app the CDN runs (I know not all CDNs run cloud app hosting services,
but some do)). Note that even though all sites are served by the same
server, all sites suffer the risk profile of the highest-profile site. If a
CDN server is serving tiny.unknown.com and also mega.often-attacked.net,
tiny.unknown effectively endures attacks on mega.often-attacked.

* Questionable reseller. Although reselling a CDN might normally give you
access only to a subset of the CDN's subscriber's sites, you can get many in
one go because these certs have so many subjects. See below.

 The bulk of the FQDNs included in the certificate are for subdomains like
 media., www-cdn., static., and the like.  Apply a different test: Is it
 bad for various organizations to use the same CDN for services over http?
 Is it bad for all those different FQDNs to CNAME to the same DNS entry and
 point to the same IP address?  Is it bad for a CDN to host multiple
 individual SSL certificates for its customers on the same set of hardware?

Let's just say I'd rather get the advantages of a CDN by other means, but
that I recognize that using a CDN can be a reasoanble economic trade-off in
many situations.

 If not, then what is so abhorrent about their various FQDNs being included
 in a single SSL certificate?

I wouldn't say abhorrent, but the increased size of the cert could be a
concern.

I just wiresharked an HTTPS connection to https://ne.edgecastcdn.net/. The
cert is 7,044 bytes. Admirably small given how many names are in it, but
still 6 KB larger than another cert I observed containing only one subject.

I have a hard enough time convincing people that HTTPS is not the root of
their web app performance problems and that therefore they CAN afford to use
it; the last thing we need is a certificate that big increasing latency at a
critical time in the page load. TLS sessions to that server don't seem to
last very long either, increasing the frequency of cert delivery; but maybe
that is necessary due to the high traffic such a server handles. (Gotta have
a limit on the size of the session store.)

I know it's a small thing, especially relative to the general content layer
heft of most sites, but still. When trying to convince developers to use
HTTPS, I need every rhetorical advantage I can get. :)

 Considering the business incentives landscape, is it safe to assume a
 strong incentive for a CDN running all those sites to be vigilant about
 their own server security?  Are there any inherently skewed incentives
 that I'm just not seeing which would lead a CDN to be negligent in its
 management of its network security and the SSL certificates it manages?

As Peter noted, http://www.webhostingtalk.com/showthread.php?t=873555.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Peter Gutmann

Paul Tiemann paul.tiemann.use...@gmail.com writes:

[...]

This is kind of a long message to reply to so I'll just post a meta-reply to
avoid getting bogged down in nitpicking, the message, as the subject line
indicated, was intended to start a discussion on some of the weaknesses
inherent in the SSL and commercial PKI model.  I consciously worded it to
avoid mentioning any CA names, and only mentioned Edgecast because it was
impossible not to (I had to provide a URL for the cert), and even then
included a disclaimer that it wasn't a criticism of Edgecast.  I actually
agree with a lot of the points made in the response, since this wasn't a
failing of Edgecast or a CA but a problem in the way SSL's PKI (or more
generally just PKI as a whole) works.  Because it was designed for the
purposes of authenticating a single user to the global X.500 directory it
really doesn't have any provision for Sybil certs (I'm going to keep calling
them that because we need some sort of label for them :-).

The intent with posting it to the list was to get input from a collection of
crypto-savvy people on what could be done.  The issue had previously been
discussed on a (very small) private list, and one of the members suggested I
post it to the cryptography list to get more input from people.  The follow-up
message (the Part II one) is in a similar vein, a summary of a problem and
then some starters for a discussion on what the issues might be.

So a general response to the several well, what would you do? questions is
I'm not sure, that's why I posted this to the list.  For example should an
SSL cert be held to higher standards than the server it's hosted on?  In other
words if it's easier to compromise a CDN host or (far more likely) a web app
on it, does it matter if you're using a Sybil cert?  I have no idea, and I'm
open to arguments for and against.

I've spoken with my contacts at Edgecast, and they expressed that they're
very willing to consider alternate approaches.

I'm not actually sure what the fix would be for this, or even if there is a
fix that needs to be made.  Thus the hope to get it discussed on the list.

(Oh, and a comment on the XS* bit, that was based on an earlier off-list
discussion on messing with Firefox' same-origin policy protection mechanism
and isn't relevant here, the real issue is the more obvious one of a single
cert acting for large numbers of totally unrelated domains with very different
security requirements).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Peter Gutmann
Ian G i...@iang.org writes:

**  But talking about TLS/SNI to SSL suppliers is like talking about the
lifeboats on the Titanic ... we don't need it because SSL is unsinkable.

... or talking to PKI standards groups about adding a CRL reason code for
certificate issued in error (e.g. to an imposter).  This was turned down
because CA's never make mistakes, so there's no need to have such a reason
code.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Ralph Holz
Hi,

 Eckersley's and Burns' presentation at Defcon (coming right up) will present
 their findings from a global survey of certs presented by hosts listening on
 port 443. Their results are disturbing.

Have these results already been published somewhere, or do you maybe
even have a URL?

Ralph

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Anne Lynn Wheeler

On 07/27/2010 10:11 AM, Peter Gutmann wrote:

So a general response to the several well, what would you do? questions is
I'm not sure, that's why I posted this to the list.  For example should an
SSL cert be held to higher standards than the server it's hosted on?  In other
words if it's easier to compromise a CDN host or (far more likely) a web app
on it, does it matter if you're using a Sybil cert?  I have no idea, and I'm
open to arguments for and against.


long ago and far away, we were called in to consult with a small client/server startup that wanted 
to do payment transactions on their server ... they had also invented this technology called SSL 
that they wanted to use. As part of applying the technology to the business payment process ... we 
also had to go around and investigate how some of these new businesses, calling themselves 
Certification Authorities, operated. In any case, the result is now sometimes called 
electronic commerce.

There were lots of issues with deficiencies and vulnerabilities, resulting in my coining 
the term merchant comfort certificates ... aka ... as opposed to anything to 
do with security. Of course, I also suggested that everybody that in anyway touched on 
the certificates or the merchant servers ... needed to have detail FBI background check.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Pat Farrell
  On 07/27/2010 11:04 AM, Anne  Lynn Wheeler wrote:

   long ago and far away. they had also invented this technology
   called SSL that they wanted to use. As part of applying the
   technology to the business payment process ... we also had to go
   around and investigate how some of these new businesses, calling
   themselves Certification Authorities, operated.

In that same time, I was at CyberCash, we invented what is now
sometimes called electronic commerce.  and that and $5 will get
you a cup of coffee. We predated SSL by a few years. Used RSA768 to
protect DES sessions, etc. Usual stuff.

One complaint that we got a lot was that we did not use certs or
CAs. CyberCash was the only trusted source.



   There were lots of issues with deficiencies and vulnerabilities

Most of which we avoided by skipping the cert concept. Still, better
technology has nothing to do with business success.

Public Key Crypto with out all the cruft of PKI. Its still a good
idea.

Pat

-- 
Pat Farrell
http://www.pfarrell.com/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Anne Lynn Wheeler

On 07/27/2010 12:09 PM, Pat Farrell wrote:

Most of which we avoided by skipping the cert concept. Still, better
technology has nothing to do with business success.

Public Key Crypto with out all the cruft of PKI. Its still a good
idea.


that became apparent in the use of SSL between all the merchant servers and the 
payment gateway. by the time the registration and setup process was completed 
at both ends ... the certificate was purely an artificial attribute of the 
crypto library being used. there were other issues with the payment gateway 
protocol ... i was able to mandate things like mutual authentication ... which 
didn't exist in the crypto library up to that point ... however the exchange of 
certificates was so engrained that it wasn't possible to eliminate (even tho 
all the necessary information already existed at both end-points).

the merchant server/browser part ... I could only recommend ... I couldn't 
mandate.

my analogy is that certificates  PKI are electronic analogy of the letters of 
credit/introduction from the sailing ship days ... when the relying party had no 
other recourse for information about the stranger that they were dealing with. This 
was left over from the dail-up email days of the early 80s (dial-up electronic 
post-office, exchange email, hangup, and possibly have first-time email from 
complete stranger).

that design point was quickly vanishing in the 90s with the pervasive growth of 
the online internet.

I as at annual ACM sigmod conference in the early 90s ... and one of the big 
sessions, somebody asked on of the panelists what was all this x.50x gorp about. 
Eventually somebody explained that it was a bunch of networking engineers 
attempting to re-invent 1960s database technologies  with certificates being 
armored, stand-alone, stale representation of some information from a database 
someplace. In the later 90s, certificates attempted to find place in no-value 
market niches (aka, situations involving no-value operations that couldn't justify 
online /or real-time information) ... although this got into some conflicts 
... trying to address no-value market-niche ... at the same time claiming 
high-value, expensive operation.

There were businesses cases floated to venture community claiming $20B 
certificate market ... i.e. that every person in the country would have 
$100/annum certificate ... some predicting that the financial community would 
underwrite the cost. When that didn't happen, there were other approaches. We 
had been called in to help wordsmith the cal. state electronic signature 
legislation ... which was being heavily lobbied by the PKI industry to mandate 
certificates.

I could that rube-goldberg OCSP was response to interaction I had with some of 
the participants ... somebody bemoaning the fact that the financial industry 
needed to be brought into 20th century requiring certificates appended to every 
financial transaction. I responded that stale, static certificates would be 
retrenching to before the advent of online, real-time point-of-sale payment 
transactions ... aka a major step backward, not a step forward.

Besides the appending a stale, static certificate to every payment transaction being 
redundant and superfluous ... it also represents enormous overhead bloat. There were some 
reduced financial, relying-party-only certificates being floated in the 
mid-90s ... which were still 100 times larger than the typical payment payload size 
(increase the size of payment transaction payload by a factor of 100 times for no 
beneficial purpose).

The X9 financial standard group ... had some participants recognizing the 
enormous overhead bloat certificates represented in payments started a 
compressed certificate standards activity ... possibly looking to reduce the 
100 times overhead bloat to only 5-10 times overhead bloat (although still 
redundant and superfluous). One of their techniques was that all information 
that was common in every certificate ... could be eliminated. Then all 
information that the relying party already had could be eliminated. I was able 
to trivial show, that a relying party would have access to every piece of 
information in a certificate ... and therefor digital certificates could be 
compressed to zero bytes.

Then rather than arguing whether it was mandated that every payment transaction 
have an appended certificate ... we could mandate that every payment 
transaction have a zero-byte appended certificate.

disclaimer ... eventually had a couple dozen (assigned, retain no interest) 
patents in the area of certificate-less public key (some showing up long after 
we were gone) ... summary here
http://www.garlic.com/~lynn/aadssummary.htm

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com



Re: A mighty fortress is our PKI

2010-07-27 Thread Chris Palmer
Ralph Holz writes:

  Eckersley's and Burns' presentation at Defcon (coming right up) will
  present their findings from a global survey of certs presented by hosts
  listening on port 443. Their results are disturbing.
 
 Have these results already been published somewhere, or do you maybe even
 have a URL?

Defcon is the publishing event; and Black Hat for Ristic's material. It's in
a few days (Friday evening for Ekersley and Burns). Also keep an eye on the
eff.org site, I bet they'll say something there too. Possibly also at
isecpartners.com.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Anne Lynn Wheeler

On 07/27/2010 12:09 PM, Pat Farrell wrote:

In that same time, I was at CyberCash, we invented what is now
sometimes called electronic commerce.  and that and $5 will get
you a cup of coffee. We predated SSL by a few years. Used RSA768 to
protect DES sessions, etc. Usual stuff.


somewhat as result of doing the SSL payment stuff ... in the mid-90s got invited to 
be part of the x9a10 financial standard working group ... which had been given the 
requirement to preserve the integrity of the financial infrastructure for all 
retail payments. the result was x9.59 retail payment financial standard ... which 
was specific in such a way that it would work with any secure authentication 
(including allowing both certificate  certificate-less mode). The business 
process was slightly tweaked so it was no longer necessary to hide the information 
in a payment transaction to preserve the financial infrastructure integrity. This 
didn't eliminate skimming, evesdropping, data breaches ... but it eliminated the 
ability for the attackers to use the information to perform fraudulent transactions 
(and effectively also eliminates the major use of SSL in the world ... hiding the 
information in financial transaction).

About the same time the x9a10 standards work was going on ... there were a 
couple other payment transaction specification work occurring ... which were 
mandating certificate operation ... somewhat trying to side-step the 100 times 
payload bloat. they would strip the certificate at internet gateway ... and 
forward the transaction thru the standard payment network with flag turned on
(they could somewhat wave their hands that 100 times payload bloat on the internet was 
immaterial ... but not so in the real payment network) that certificate processing had 
occurred (compared to light-weight, super secure, x9.59 ... which operated end-to-end). 
There were later some presentations at ISO standards meetings that transactions were 
showing up with the certificate flag on ... but they could prove no 
certificate had been involved (i.e. there was financial interchange fee benefit 
motivating turning on the flag).

shortly after they had published their (certificate-based) payment 
specification (but well before any operational code), I did a public-key op 
profile for their specification. I then got a friend that had a optimized BSAFE 
library (ran four times faster) to benchmark the profile on lots of different 
platforms ... and then reported the results to the groups publishing the 
profile. The response was my numbers were 100 times too slow (if they had 
actually run any numbers, their comment should have been it was four times too 
fast). Some six months later when they did have pilot code ... my profile 
numbers were within a couple percent of actual (i.e. the BSAFE library changes 
had been incorporated into standard distribution).

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Chris Palmer
Sampo Syreeni writes:

 I am not sure what quantitative measurement of vulnerability would even
 mean. What units would said quantity be measured in?
 
 I'm not sure either. This is just a gut feeling.

See also:

http://nvd.nist.gov/cvsseq2.htm

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Perry E. Metzger
On Tue, 27 Jul 2010 11:11:52 -0700 Chris Palmer
ch...@noncombatant.org wrote:
 Sampo Syreeni writes:
 
  I am not sure what quantitative measurement of vulnerability
  would even mean. What units would said quantity be measured in?
  
  I'm not sure either. This is just a gut feeling.
 
 See also:
 
 http://nvd.nist.gov/cvsseq2.htm

That scale seems remarkably arbitrary.

One problem with such arbitrary scales is that there is no objective
methodology one can engage in which will show that the equation is
wrong in some way.

Unless you can perform an experiment to falsify the self-declared
objective quantitative security measurement, it isn't science. I
can't think of an experiment to test whether any of the coefficients
in the displayed calculation is correct. I don't even know what
correct means. This is disturbing.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Chris Palmer
Perry E. Metzger writes:

 Unless you can perform an experiment to falsify the self-declared
 objective quantitative security measurement, it isn't science. I can't
 think of an experiment to test whether any of the coefficients in the
 displayed calculation is correct. I don't even know what correct
 means. This is disturbing.

I can recommend a good single-malt scotch or tawny port if you like. Have
you tried the Macallan 18?

False metrics are rampant in the security industry. We really need to do
something about them. I propose that we make fun of them.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread dan

  False metrics are rampant in the security industry. We really need
  to do something about them. I propose that we make fun of them.


You might consider joining us in D.C. on 10 August at
http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon5.0

--dan, program committee

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Ben Laurie
On 27/07/2010 15:11, Peter Gutmann wrote:
 The intent with posting it to the list was to get input from a collection of
 crypto-savvy people on what could be done.  The issue had previously been
 discussed on a (very small) private list, and one of the members suggested I
 post it to the cryptography list to get more input from people.  The follow-up
 message (the Part II one) is in a similar vein, a summary of a problem and
 then some starters for a discussion on what the issues might be.

Haven't we already decided what to do: SNI?

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-07-27 Thread Ben Laurie
On 24/07/2010 18:55, Peter Gutmann wrote:
 - PKI dogma doesn't even consider availability issues but expects the
   straightforward execution of the condition problem - revoke cert.  For a
   situation like this, particularly if the cert was used to sign 64-bit
   drivers, I wouldn't have revoked because the global damage caused by that is
   potentially much larger than the relatively small-scale damage caused by the
   malware.  So alongside too big to fail we now have too widely-used to
   revoke.  Is anyone running x64 Windows with revocation checking enabled and
   drivers signed by the Realtek or JMicron certs?

One way to mitigate this would be to revoke a cert on a date, and only
reject signatures on files you received after that date.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Nicolas Williams
On Tue, Jul 27, 2010 at 09:54:51PM +0100, Ben Laurie wrote:
 On 27/07/2010 15:11, Peter Gutmann wrote:
  The intent with posting it to the list was to get input from a collection of
  crypto-savvy people on what could be done.  The issue had previously been
  discussed on a (very small) private list, and one of the members suggested I
  post it to the cryptography list to get more input from people.  The 
  follow-up
  message (the Part II one) is in a similar vein, a summary of a problem and
  then some starters for a discussion on what the issues might be.
 
 Haven't we already decided what to do: SNI?

But isn't that the problem, that SNI had to be added therefore it isn't
everywhere therefore site operators don't trust its presence therefore
SNI is irrelevant?

Do we have any information as to which browsers in significant current
use don't support SNI?  Hopefully at some point site operators could
declare that browsers that don't support SNI will not be supported.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-07-27 Thread Paul Tiemann
On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote:

 On 24/07/2010 18:55, Peter Gutmann wrote:
 - PKI dogma doesn't even consider availability issues but expects the
  straightforward execution of the condition problem - revoke cert.  For a
  situation like this, particularly if the cert was used to sign 64-bit
  drivers, I wouldn't have revoked because the global damage caused by that is
  potentially much larger than the relatively small-scale damage caused by the
  malware.  So alongside too big to fail we now have too widely-used to
  revoke.  Is anyone running x64 Windows with revocation checking enabled and
  drivers signed by the Realtek or JMicron certs?
 
 One way to mitigate this would be to revoke a cert on a date, and only
 reject signatures on files you received after that date.

I like that idea, as long as a verifiable timestamp is included.

Without a trusted timestamp, would the bad guy be able to backdate the 
signature?

Paul Tiemann
(DigiCert)
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Paul Tiemann
On Jul 27, 2010, at 1:14 PM, d...@geer.org wrote:

 False metrics are rampant in the security industry. We really need
 to do something about them. I propose that we make fun of them.
 
 
 You might consider joining us in D.C. on 10 August at
 http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon5.0
 
 --dan, program committee

Wow, I was just going to recommend Dan's book, Security Metrics.

Anyone tasked with quantifying actual security should read his book.  There's a 
pretty good dissection of ALE, and a fantastic few chapters about building a 
balanced scorecard to measure your operations from more perspectives than just 
dollars and cents.

When I read that nist.gov link, the joke about the spherical cow popped into my 
head.

Paul Tiemann
(DigiCert)

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Paul Tiemann
 Haven't we already decided what to do: SNI?
 
 But isn't that the problem, that SNI had to be added therefore it isn't
 everywhere therefore site operators don't trust its presence therefore
 SNI is irrelevant?

It appears Apache supports SNI as of 2.2.12 which was released 12 months ago.

 Do we have any information as to which browsers in significant current
 use don't support SNI?  Hopefully at some point site operators could
 declare that browsers that don't support SNI will not be supported.

The worst of the show stoppers is IE on Windows XP.  No SNI support.

IE6 is still at 7.2% as of June 2010.  It was 14.4% in June 2009.  

http://www.w3schools.com/browsers/browsers_stats.asp

... is it possible to help IE6 and other non-SNI browsers to die faster?

 Perry suggested reading Orwell's essay, Politics and the English Language.  
Think about Orwell's opening sentence:

Most people who bother with the matter at all would admit that the English 
language is in a bad way, but it is generally assumed that we cannot by 
conscious action do anything about it.

Now replace the English language with PKI

Then...

There is a long list of flyblown metaphors which could similarly be got rid of 
if enough people would interest themselves in the job; and it should also be 
possible to laugh the not un- formation out of existence*...

*One can cure oneself of the not un- formation by memorizing this sentence: A 
not unblack dog was chasing a not unsmall rabbit across a not ungreen field.

So...

There is a long list of outdated browsers which could be got rid of if enough 
people would interest themselves in the job.

One fast way to pressure technological change is for the world to move on to 
better things and leave the legacy stuff behind.  Who uses Netscape 4 or IE 5 
any more?  Those were left behind because everyone in web design wanted CSS 
support and just started using CSS.  The web design field desperately wants to 
be throwing IE6-is-dead parties.  Could some intelligent web designers come up 
with a few snippets of code in the various web flavors (PHP, ASP, JSP, etc) for 
people to easily install and include on their sites (as part of a movement to 
discourage old browser usage and encourage better security on the web...)  If 
an old browser is detected, a friendly warning message or even an error message 
appears, along with links to the site explaining the movement...  Of course it 
would only be grassroots, but I've heard enough rumbling on web designer blogs 
to think that someone might just take up a cause like that.  The security 
community could encourage it maybe?  Put a Paypal button on there.  I know a 
lot of people who would donate money.  

Looks like at least one site is out there: http://ie6update.com/ but has no 
Paypal donate button, and doesn't offer newcomers the reasons they should 
switch to something more modern.

Maybe this is too utopian.  But laughing does work, sometimes.

Paul Tiemann
(DigiCert)
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Paul Tiemann
 **  But talking about TLS/SNI to SSL suppliers is like talking about the
 lifeboats on the Titanic ... we don't need it because SSL is unsinkable.

Apache support for this came out 12 months ago.  Does any one know of 
statistics that show what percentage of installed Apache servers out there are 
running 2.2.12 or greater?  How many of the top 10 Linux distributions are past 
2.2.12?  

A CDN might be able to push SNI forward for its own platform, but mass adoption 
isn't coming until we also have broad compatibility among the client browsers.  
SSL certs as they are currently being used are not good for much if they cause 
a bunch of browser warnings, so I can't see how you could really expect SSL 
suppliers to blast holes in their own Titanic.  New standards are wonderful, 
but who can use them until they're well supported?

This page says iPhone IOS4 supports SNI.  That just came out.

http://en.wikipedia.org/wiki/Server_Name_Indication

 ... or talking to PKI standards groups about adding a CRL reason code for
 certificate issued in error (e.g. to an imposter).  This was turned down
 because CA's never make mistakes, so there's no need to have such a reason
 code.

I wasn't around when this happened, but maybe revoking for Key compromise was 
considered just as good.  And maybe it's rare enough not to need its own 
special if() statement in all the browsers.  The browsers don't really do 
different things based on the reason code anyway (to my knowledge) 

Paul Tiemann
(DigiCert)
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Jack Lloyd
On Tue, Jul 27, 2010 at 06:07:02PM -0600, Paul Tiemann wrote:


 IE6-is-dead parties.  Could some intelligent web designers come up
 with a few snippets of code in the various web flavors (PHP, ASP,
 JSP, etc) for people to easily install and include on their sites
 (as part of a movement to discourage old browser usage and encourage
 better security on the web...)  If an old browser is detected, a
 friendly warning message or even an error message appears, along
 with links to the site explaining the movement...

Already exists:

http://code.google.com/p/ie6-upgrade-warning/ - JS, displays a nice
dialog telling the user why they should upgrade and links to download
a new IE, Firefox, Chrome, etc.

http://drupal.org/project/iedestroyer - Drupal (CMS) plugin

http://www.crashie.com/ - if you're feeling malicious, just include
the one line JavaScript that will make IE6 crash, maybe eventually the
user will figure it out. (Or maybe not).

Or a block of pretty much plain old HTML:

http://www.codingforums.com/showthread.php?t=196674

Ultimately though, the only thing that's going to get some people off
IE6 is the machines they are running it off of finally dying, either
due to hardware failure or being so badly owned by worms that the
machine becomes inoperable, at which point it goes into the trash
and they buy a new one.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Nicolas Williams
On Tue, Jul 27, 2010 at 06:30:51PM -0600, Paul Tiemann wrote:
  **  But talking about TLS/SNI to SSL suppliers is like talking about the
  lifeboats on the Titanic ... we don't need it because SSL is unsinkable.
 
 Apache support for this came out 12 months ago.  Does any one know of
 statistics that show what percentage of installed Apache servers out
 there are running 2.2.12 or greater?  How many of the top 10 Linux
 distributions are past 2.2.12?  

Yet browser SNI support is what matters regarding adoption.  No hosting
service will provision services such that SNI is required if too much of
the browser installed base does not support it.

Of course server support is a requirement in order to get SNI deployed,
but that's much less of an issue than client support.

Thanks for pointing out IE6 though.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Paul Tiemann
Hi Peter,

 I actually
 agree with a lot of the points made in the response, since this wasn't a
 failing of Edgecast or a CA but a problem in the way SSL's PKI (or more
 generally just PKI as a whole) works.  

Yes.  SNI could have been included from the start, but it was probably hard 
enough back then to get SSL 1.0 or SSL 2.0 out the door.  It's difficult for a 
CA to push new SSL extensions if SSL clients aren't ready for what's new.

 Because it was designed for the
 purposes of authenticating a single user to the global X.500 directory it
 really doesn't have any provision for Sybil certs (I'm going to keep calling
 them that because we need some sort of label for them :-).

Agreed.  PKI was designed in a time when IPv4 space was a lot more plentiful 
too, and few had even dreamt of serving from multiple locations via anycast.  A 
lot of the time (for good or bad) new pressures form around a problem and 
people invent new ways of using old things.  It's often easier to reuse an 
older well supported feature of BGP, TCP or even SSL than to go invent 
something wonderful and new and then wait years for the world to catch up 
(think SNI.)

The designers of PKI couldn't foresee all possible future uses, and 
implementation wasn't perfect from the start.  It wasn't until 2007 that the 
Subject Alternative Name started to see mass adoption, and that was due 
mainly to Microsoft pushing for it (they had supported it since Windows 95!) 
which ought to be considered a good thing.

I won't object to 'Sybil' as long as it's understood to mean multi-personality 
and not deception.

 The intent with posting it to the list was to get input from a collection of
 crypto-savvy people on what could be done.  

I'll admit that at first it appeared to have been posted as something to be 
laughed at.  After reading Perry's recommended Orwell essay, I'm willing to 
admit that laughing at things can be a way to effect change.  

 The issue had previously been
 discussed on a (very small) private list, and one of the members suggested I
 post it to the cryptography list to get more input from people.  The follow-up
 message (the Part II one) is in a similar vein, a summary of a problem and
 then some starters for a discussion on what the issues might be.

Part II was nice.  Shocking and full of thought provoking questions too.

 For example should an
 SSL cert be held to higher standards than the server it's hosted on?  In other
 words if it's easier to compromise a CDN host or (far more likely) a web app
 on it, does it matter if you're using a Sybil cert?  I have no idea, and I'm
 open to arguments for and against.

My technical contention is that it's generally going to be harder to compromise 
an origin caching CDN host because they do not run any web app code at all:

Pseudo code for a CDN http daemon:

init
while 1:
read a request
if already cached: serve the request from cache
else: fetch from origin, save to cache if cacheable, and serve

If running PHP/ASP/Java/etc then those bets are off, but a CDNs don't do this.  
Many CDNs just serve up static (non-origin cached, no POST support) sites.

 I've spoken with my contacts at Edgecast, and they expressed that they're
 very willing to consider alternate approaches.
 
 I'm not actually sure what the fix would be for this, or even if there is a
 fix that needs to be made.  Thus the hope to get it discussed on the list.

Well, if nothing else, the smaller certificates might at least help whatever 
PKI library was getting the segv.

Paul Tiemann
(DigiCert)

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Sampo Syreeni

On 2010-07-28, Peter Gutmann wrote:

... or talking to PKI standards groups about adding a CRL reason code 
for certificate issued in error (e.g. to an imposter).  This was 
turned down because CA's never make mistakes, so there's no need to 
have such a reason code.


Personally what I wonder about is that there is precious little research 
on how difficult and/or worthwhile it is to circumvent the formal, 
mathematical crypto-stuff, as a whole. We all know that is bound to be 
the hardest part if somebody wants to hurt you, so why center your 
attention there? Why not go for the soft flesh instead?


Perry already caught me on that basic security questionnaire, when I 
asked for numbers and couldn't answer. Now I'm thinking the proper 
figure should probably be ratio of investment into a security break, 
against benefit from the same. Including existing safeguards against 
said break. That should be fair enough, and should help us optimize 
against future security breaks at the margin, no?

--
Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front 
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com