Subject: Re: [TLS] Eleven out of every ten SSL certs aren't valid

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 1 Jul 2010 12:05:09 -0600

Peter said: (combining two different posts)

> his is the same thing, the figure is very meaningful
> because it supports the analysis of the effects of externalities on web site
> security done by some guys at Microsoft Research a few months ago which
> pointed out that since certificate warnings are close to one hundred percent
> false positives (they were aware of no known cases in which someone had been
> saved from being phished by a cert warning),

>  "So Long, And No Thanks for the Externalities: The Rational Rejection of
>  Security Advice by Users", Cormac Herley, Proceedings of the 2009 New
>  Security Paradigms Workshop (NSPW.09), September 2009, p.133.

The problem of course is that this is purely anecdotal.  Cormac didn't cite any research pointers for that, and it is at the heart of the current debate.   If we can actually check for users receiving self-signed certificate warnings when browsing the ordinary web (and perhaps not their corporate intranets) and get some real data about how frequently users actually get these warnings, and/or get MITM'd, then we'd really be getting somewhere.

Frankly, if you think most certificate warnings are false positives, and you also believe that they will forever be such, then why do any certificate verification at all?   This line of reasoning essentially says "there aren't really any active MITM attackers, and won't ever be" so let's just do away with the whole mess of ever checking certificates.

If you want to stop not just attacks today, but attacks that active attackers move to, you need to actually worry about the real numbers here, and the potential for abuse. This does argue for a change in client behavior, but not perhaps in the way some people have suggested - removing all warnings about self-signed certificates.  I don't think that helps us long term.

--
Andy

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 02 Jul 2010 15:54:46 +1200

"Steingruebl, Andy" <[email-masked]> writes:

>The problem of course is that this is purely anecdotal.  Cormac didn't cite
>any research pointers for that, and it is at the heart of the current debate.

You mean the fifty-three references he gave weren't enough?  (OK, most of them
aren't to evaluations of the effects of cert warnings, but several are).  A
related problem is that there's been so much work done on the (lack of)
effects of cert warnings, and certs in general, that he could have spent half
the paper just regurgiating all the existing work.

(I'm dreading someone asking "OK, list all these refs" because then I'll have
to go away and spend several hours digging them all up... how many do people
want before they say "OK, that's enough"?.  Cormac's paper has about eight,
and that's barely scratching the surface).

>Frankly, if you think most certificate warnings are false positives, and you
>also believe that they will forever be such, then why do any certificate
>verification at all?

Precisely.  Users just click past them anyway.  Let's just admit that what
users are getting now is effectively unauth'd DH and then try and give them
something that actually works.

>This line of reasoning essentially says "there aren't really any active MITM
>attackers, and won't ever be" so let's just do away with the whole mess of
>ever checking certificates.

No, it says that what we're doing doesn't work, has never worked, and as far
as anyone can tell will never work (and we have a multibillion(?) dollar
global cybercrime indistry to prove it), so lets look for alternatives that do
work.  So we can do away with the mess of certs not because there aren't any
attacks but because they cost a ton of money and effort without actually
working.

(That's one statistic I'd like to see, if there are X sites using CA-bought 
certs costing an average of $Y and it takes a site admin A time at $B an hour, 
how much is the PKI phantomime costing per year?  Cormac has already given 
figures for how much clicking past all the warnings costs on the user side, 
but what does it cost to create the mess in the first place?).

Peter.

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 1 Jul 2010 23:57:08 -0600

> -----Original Message-----
> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Thursday, July 01, 2010 8:55 PM
> To: Steingruebl, Andy; [email-masked]
> Subject: Re: [TLS] Eleven out of every ten SSL certs aren't valid
> 
> >The problem of course is that this is purely anecdotal.  Cormac didn't
> >cite any research pointers for that, and it is at the heart of the current
> debate.
> 
> You mean the fifty-three references he gave weren't enough?  (OK, most of
> them aren't to evaluations of the effects of cert warnings, but several are). 

Sorry, the cite I found lacking was the one that said all cert warnings are false positives.  There is no published research that I know of that actually has tried to do a widescale measurement of active MITM attacks against SSL.  I know of at least 2 in progress, but neither is published yet.  This is the data I'm looking for.  You are right that the problem with certificate warnings has been studied in depth, I wasn't questioning that.  

> as anyone can tell will never work (and we have a multibillion(?) dollar global
> cybercrime indistry to prove it), so lets look for alternatives that do work.  So
> we can do away with the mess of certs not because there aren't any attacks
> but because they cost a ton of money and effort without actually working.

Again this is a question of what problem one is trying to solve, but I can concede that the existing ecosystem isn't working.  I don't know that cybercrime is flouring because of the global PKI and CAs, right?  Are you really trying to argue that because certificate warnings don't stop cybercrime, they aren't worthwhile?  I'm not sure I understand how you get to there from here.

> (That's one statistic I'd like to see, if there are X sites using CA-bought certs
> costing an average of $Y and it takes a site admin A time at $B an hour, how
> much is the PKI phantomime costing per year?  Cormac has already given
> figures for how much clicking past all the warnings costs on the user side, but
> what does it cost to create the mess in the first place?).

Again, without real attack/threat data that tells us how many active MITM attackers there are, I don't think we know the costs of clicking through cert warnings.  He assumes they are all false positives, something I'm not prepared to buy.  

Do you know of some published data on the number of malicious wifi access points, SSL mitm attacks, etc. that I don't?  Its possible I just haven't seen it.

--
Andy

---

From: Marsh Ray <[email-masked]>
Date: Fri, 02 Jul 2010 03:47:23 -0500

On 07/01/2010 10:54 PM, Peter Gutmann wrote:
>
> (I'm dreading someone asking "OK, list all these refs" because then
> I'll have to go away and spend several hours digging them all up...
> how many do people want before they say "OK, that's enough"?.
> Cormac's paper has about eight, and that's barely scratching the
> surface).

I believe you - surely most people will click through most warnings most
of the time.

> No, it says that what we're doing doesn't work, has never worked, and
> as far as anyone can tell will never work (and we have a
> multibillion(?) dollar global cybercrime indistry to prove it), so
> lets look for alternatives that do work.

But still, most of those people lost their online banking credentials to 
the global cybercrime industry to a phishing email, because they use the 
same password everywhere, because their endpoint PC is owned by a 
keylogging botnet, or all of the above. They got this way by buying 
downloading commercial application software in brightly colored boxes, 
not keeping it up-to-date, and trusting a UI when it says "this 
executable is signed and has a shield icon, click OK to let it own your 
computer".

They likely did not get owned by a MitM of their SSL/TLS connection 
where they clicked through a scary page.

Some observations:

1. This is not evidence that "browser warnings are ineffective". If 
anything it shows that HTTPS is categorically better than most other 
parts of this system.

2. These users are completely incompetent relative to the impossibly 
hard job of keeping a general-purpose computer secure while consuming 
content from the hostile internet. (This is not to say anything bad 
about them, they are probably wiser for not wasting too much personal 
energy on managing data security.) It will be forever impossible to keep 
them "safe online", just like 200 years of experience in postal 
technology has not eliminated mail fraud.

Therefore I strenuously object to this "least-common-denominator users 
confidently spending money online" model being allowed to drive the 
discussion of TLS. It is simply not possible to have a meaningful 
technical discussion about a cryptographic data security protocol unless 
we can agree that both Alice and Bob have a baseline of self-interest 
and competence to secure their endpoints.

>Let's just admit
> that what users are getting now is effectively unauth'd DH and then
> try and give them something that actually works.

No! Not this user, and not the systems I help to build and deploy. There 
are all kinds of interesting, embedded, automated, unattended, and 
large-scale systems successfully using TLS for securing critical data 
communications.

More importantly, there _are_ careful and conscientious admins who do a 
totally professional job at maintaining their production systems 
according to recommended best practices. It is the requirements of this 
group that TLS must be optimized to meet. For if the competent 
professional cannot successfully employ the full security of this 
protocol, what chance does that leave for the typical user?

Consider the biggest shift in data processing in decades is cloud 
computing. Cloud management and seemingly every piece of new networking 
gear presents a web-based admin UI for use with your ordinary browser. 
So the security of the apps, documents, servers, VPNs, and even big 
parts of the network itself has been rebuilt atop TCP port 443.

This architecture self-organized due to powerful economic and social 
forces, not because anyone felt it was the best way from a security 
perspective. So we really have no choice but to get our protocol 
primitives nailed down air-tight:

* Users must be informed of the essential role they have in the security 
architecture. They need to know a bit more of the mechanics of PKI in 
order to bring to bear the common sense that people are actually pretty 
good at. I suspect most people will take it seriously and can actually 
do a respectible job of it, just like most people understand not to use 
a hair dryer in the bathtub. Note that that little bit of user education 
cost neither bathtubs nor hair dryers any market share.

* PKI built on the absolute trust of hundreds of omnipotent root certs 
from friend and foe alike just doesn't cut it any more. Vendors of the 
disintegrating status quo need to lead with some real improvements or 
embrace obsolescence.

* Server admins need to be informed that HTTPS does not allow the server 
to prove the nonexistence of a MitM, the protocol relies on the client 
to do a good job of this. Therefore the server ends up having no choice 
but to transitively trust the union of all the sets of trusted root 
certs of all the clients that could be used to access the system.

* TLS client certificate auth can allow the server to disprove the MitM. 
Web clients and servers should implement first-rate support for this 
configuration and provide integrated tools for users and admins to 
manage them.

* A limited, securable subset of this insane layer cake of protocols we 
currently call "the web" needs to be precisely defined and adopted. Its 
use must become accepted as required best practice in security critical 
contexts, much like https has. It must include a browser security model 
with well-defined and strong boundaries.

* Much as we once thought security would result naturally from a 
thorough analysis of functional requirements, current designs sometimes 
meet stated security goals yet have undesirable properties relating to 
expectations of privacy. Mechanisms for identifying and metadata tagging 
relevant information (as we may sometimes retain character data encoding 
information) and implementing data handling policies (much like database 
integrity constraints) should be standardized.

* The identities of all parties contributing content, script, and 
cookies affecting the current page need to be prominently displayed and 
greatly restricted for secure systems. There may yet still be time to 
prevent your firewall's admin page from hosting web bugs for advertisers 
and participating in social networking mashups.

Anyway, just some thoughts on things that could use improving. It seems 
like TLS itself is decent shape and is in a good position to expand its 
role in support of some larger goals.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 03 Jul 2010 00:10:12 +1200

"Steingruebl, Andy" <[email-masked]> writes:

>Sorry, the cite I found lacking was the one that said all cert warnings are
>false positives.  There is no published research that I know of that actually
>has tried to do a widescale measurement of active MITM attacks against SSL.

Oh, sure.  OTOH I don't see how you could get figures for that, since you're
trying to prove a negative ("we detected eighteen undetected attacks last
year" :-).  The paper tries to turn this around by creating a falsifiable
hypothesis, "show me an instance where a cert warning saved a user from harm",
which is probably the best you can do.

>I know of at least 2 in progress, but neither is published yet.  This is the
>data I'm looking for.

The very fact that we're having this discussion is pretty scary, we've been
using certs in SSL/TLS for fifteen years now and we're still waiting for any
evidence about whether they're defending against anything (in terms of MITM,
not site-identification).  Imagine if someone in the automative industry said
"Yeah, well we've been building klorgleblorts into every car shipped for the
last twenty years, we're just waiting for someone to figure out whether they
serve any purpose or not" :-).

>Are you really trying to argue that because certificate warnings don't stop
>cybercrime, they aren't worthwhile?  I'm not sure I understand how you get to
>there from here.

If you have a mechanism that doesn't work then you can build on that.  In
other words if you can't be a shining example then you can serve as a horrible
warning and a spur for further research into alternatives.  There's been quite
a bit of work done on the use of other mechanisms to secure transactions with
sites, my favourite is the PARC work on site-specific browsers (SSBs), for
site authentication there's Perspectives (which hits phishers in their
critical weak spot), and then there's large amounts of work on password-based
mutual auth mechanisms and key-continuity.  There's certainly no lack of
research work being done, it's just not being adopted in any browser.

>Do you know of some published data on the number of malicious wifi access
>points, SSL mitm attacks, etc. that I don't?  Its possible I just haven't
>seen it.

No, I don't know of anything.  This works both ways though, because it also
means that there's zero evidence in support of using certs for MITM
prevention.

(Incidentally, by "MITM" I assume you mean a conventional MITM and not server
authentication spoofing, i.e. phishing.  There's plenty of data available on
phishing :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 03 Jul 2010 19:09:49 +1200

[Just a general note, if people think this is off-topic and want it moved to
 private mail I'd be happy to do that, but I think it's an interesting
 discussion, TLS is more than just getting the bits on the wire right, it's
 also a matter of applying it effectively]

Marsh Ray <[email-masked]> writes:

>But still, most of those people lost their online banking credentials to the
>global cybercrime industry to a phishing email, because they use the same
>password everywhere, because their endpoint PC is owned by a keylogging
>botnet, or all of the above.

If browsers implemented credential security properly (client-side password
deversification and failsafe mutual auth) then the only one on that list
that'd still be a threat is man-in-the-browser attacks, and for that one, once
your machine is 0wned it's pretty much game over anyway.  So there are things
that can be fixed, they're just not getting fixed.

>1. This is not evidence that "browser warnings are ineffective". If anything
>it shows that HTTPS is categorically better than most other parts of this
>system.

Uhh, going back to the list of studies again, there's been study after study
after study showing they are ineffective - they have next to no effect on user
behaviour.  I'll list just one of them:

  "You've Been Warned: An Empirical Study of the Effectiveness of Web Browser
  Phishing Warnings", Serge Egelman, Lorrie Cranor and Jason Hong, Proceedings
  of the 2008 Conference on Human Factors in Computing Systems (CHI.08), April
  2008, p.1065.

because the title sprung to mind when you mentioned "browser warnings".  These
things don't work.

>discussion of TLS. It is simply not possible to have a meaningful technical
>discussion about a cryptographic data security protocol unless we can agree
>that both Alice and Bob have a baseline of self-interest and competence to
>secure their endpoints.

My interest is in keeping real-world users secure.  If I'm providing security
tools that don't do that then I'm not doing my job properly.  It's not the
user's job to learn whatever geeky stuff I think they need to know, it's my
job to give them something that keeps them secure (or at least as secure as
possible under the circumstances, I can't do much about an 0wned PC).  So I
think it is very valid to discuss it in terms of lowest-common-denominator
users, because that's who'll be using our tools.

>No! Not this user, and not the systems I help to build and deploy. There are
>all kinds of interesting, embedded, automated, unattended, and large-scale
>systems successfully using TLS for securing critical data communications.

Uhh, but what does that have to do with protecting users going to bank and
online shopping web sites?

(Two points in response to this: (1) if you control the environment then you
can push out pretty much anything you want as your security system, including
nothing at all (geographic entitlement, to authenticate yourself you have to
enter the room where the equipment is and plug in an ethernet cable), so this
isn't really a major feat, and (2) compared to the Internet at large there are
close to zero attacks on these sorts of systems (and in the odd exceptions
when SCADA-type stuff has been attacked in the past it's been found to be
swiss cheese), so "successfully using TLS" really means "we got data from A to
B", not "it's been proven resistant to a concerted attack").

>totally professional job at maintaining their production systems according to
>recommended best practices. It is the requirements of this group that TLS
>must be optimized to meet.

Uh... I thought it was to protect Joe Sixpack from having his credit card
stolen?  Professional sysadmins are the last person you want to worry about
optimising for, any sysadmin worth his salt will be able to secure their data
given no more than chewing gumm and rubber bands.  It's the 1.7-billion or so
global population of users who aren't professional sysadmins that I'm
interested in helping, not a handful of sysadmins somewhere.

>architecture. They need to know a bit more of the mechanics of PKI in order
>to bring to bear the common sense that people are actually pretty good at.

Umm... I better not reply to a statement like this, because the response would
be... inflammatory.

>* TLS client certificate auth can allow the server to disprove the MitM. Web
>clients and servers should implement first-rate support for this
>configuration and provide integrated tools for users and admins to manage
>them.

Steffen, you've won your prize :-).

(For people who don't get the ref, it's:

 "Now comes the part where somebody replies that this is all solved by client
 certificates and the discussion is closed 'til next time...)"

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Sat, 03 Jul 2010 17:02:59 -0500

>   also a matter of applying it effectively]

Agreed, but any suggestions where?

> Marsh Ray<[email-masked]>  writes:
>

May I propose that we abandon this new term "MitB" if what we're really 
talking about is just an old compromised endpoint? It seems kind of like 
jargon to make the situation of the "owned PC" sound more sophisticated 
and complicated than it really is. But maybe I'm missing some aspect of 
its meaning that gives it utility.

> behaviour.

Note I did not say that browser warnings were effective, I said that 
this was not evidence that they were ineffective.

> My interest is in keeping real-world users secure.

Me too, but I think it's useful to split the problem into two parts:

1. Is TLS an effective and secure cryptographic protocol primitive? Does 
it deliver on the stated and implied guarantees given by its RFCs?

2. What's the best policy and UI design for web browsers to maximize the 
effective security given the human, commercial, and political factors 
involved?

I like discussing both these issues. But I think it's very useful to 
keep them separate because one of these is a solvable engineering 
problem appropriate for the [TLS] list and the other is probably not. 
Also, TLS is useful independent of web browsers and even PKI.

> If I'm providing security

Considering the LCD is certainly important. I think it's also important 
that those with the more stringent requirements (and who are willing to 
invest the time to deploy stuff properly) don't get fairly represented 
in the design process due because of our low expectations of the LCD.

But the good news is that TLS has evolved to be flexible enough to cover 
everyone's needs without having to trade off one group against each 
other. The web browser user would scarcely notice a difference between 
modern TLS and the original SSLv2, but most of us would agree that that 
one is a huge improvement over the other.

> online shopping web sites?

That's my point: there's other (critically important) stuff that uses 
TLS besides web shopping.

> isn't really a major feat,

Agreed, securing communications between systems in well-managed 
datacenters is much easier. It's also a huge and really important market.

> and (2) compared to the Internet at large there are

You're right - it may be claiming too much to say anyone is 
"successfully using TLS".

It turned out that for a long time all my datacenter systems were 
vulnerable to the renegotiation bug.But so were most of the web 
shoppers' connections, too. So we factor that out and all that remains 
for my claim is that I have deployed TLS communications between 
datacenter systems that:
- reliably transfer lots of data
- aren't susceptible to any publicly-known vulnerabilities
- protect against some trivial attacks that a web browser operated by a 
user willing to click past a cert error does not.

As you point out, that's no great feat.

> stolen?

That's a good goal too, of course, but it's not exactly the kind of 
system I work on at work.

I also object to online shopping CC security being used as some sort of 
"gold standard" use case for TLS. Sure SSL was originally cooked up at 
Netscape to convince people it was safe for them to give out their CC 
online and it's still obviously a majorly important case.

But today https is just as likely to be used to secure webmail, software 
auto-updates, SOAP web services, you name it. SMTP runs over TLS for 
goodness sake. Personal privacy is a whole new dimension for web 
security that was little considered in the original design of SSL.

The battle of the CC numbers is all but lost. The bad guys have more CCs 
than they know what to do with, they get them by the tens of thousands 
from imperfectly secured merchants (and even processing centers). But 
they were not lost due to TLS (we believe, in most cases).

> Professional sysadmins are the last person you want to worry about
> given no more than chewing gumm and rubber bands.

Perhaps, but I think he'd get more consistent results with a well 
engineered secure socket protocol in his toolbox.

>  It's the 1.7-billion or so

I'd like to help them too. But I don't see how they would be helped by a 
solution that involves weakening the theoretical maximum security of 
TLS, https, or web browsers.

> Umm... I better not reply to a statement like this, because the response would

Nah, won't bother me. We might take it off list though.

>   certificates and the discussion is closed 'til next time...)"

I didn't say it was all solved by client certs, I tried to say there was 
this one specific, under-appreciated limitation of the usual https that 
they addressed. Originally I had that sentence at the end of the bullet 
before it, I don't remember why I separated it out. It was pretty late 
when I wrote that, I plead insanity. :-)

Regards,

- Marsh

---

From: Robert Relyea <[email-masked]>
Date: Tue, 13 Jul 2010 09:40:53 -0700

> because the title sprung to mind when you mentioned "browser warnings".  These
It seems these are complaining about yesterday's UI. Most browsers no
longer use pop-up menus. You have to be quite aggressive to get through
the current screens.

The real problem, of course, is those sites that don't have valid certs.
Continuing to ratched down the ability to get to those sites is good for
the internet as a whole. Sites with invalid certs are just as dangerous
for the internet as MITM sites.

---

From: Bruno Harbulot <[email-masked]>
Date: Tue, 13 Jul 2010 18:51:17 +0100

> for the internet as MITM sites.

Then we're back on the possible subjective manner by which CA 
certificates get into browsers by default. There are consequences in 
terms of oligopoly, which might not be so good for the internet as a whole.

Best wishes,

Bruno.

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Jul 2010 02:06:19 +0200 (MEST)

> for the internet as MITM sites.

The most significant effect of this UI change is that it strengthens
the oligopol and business model of commercial CAs.  The security
benefit probably negative.

This change has made the nursing problems of people experimenting
with this technology a magnitude worse.
So a lot of people are less likely to experiment with setting
up TLS on their server out of curiosity.

And the social engineering workaround for the attackers to first
feed the Browser a new CA-Cert (which results in a much less
scary popup), with the result that now certs for every server
can be forged -- which is a magnitude worse than users accepting
an untrusted server cert for a specific server-only (minus browser
bugs in what servers they accept the user-override for).

The german description for this is "das Kind mit dem Bade ausschütten"
(throw out the baby with the bathwater).

If SSHv1 would have required CA-signed X.509 certs in its initial
shipment, it would have taken MUCH longer to become popular, if at all.

-Martin

---

From: Robert Relyea <[email-masked]>
Date: Tue, 13 Jul 2010 18:41:25 -0700

> shipment, it would have taken MUCH longer to become popular, if at all.
Compared to SSL, SSH is still not popular, which sort of negates your point.

SSL is designed to allow you to make secure connections for the masses.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Jul 2010 22:03:33 -0500

> SSL is designed to allow you to make secure connections for the masses.

Specifically it was designed to allow the masses to make secure* 
connections to e-retailers with which they had no prior agreement. 
Having a pre-trusted third party perform the introduction is probably 
the only way to accomplish that. Trust-on-first-use and PGP web-of-trust 
type models were simply not going to get the shoppers online.

*secure = Secure enough to convince people it's safe to type in their 
credit card online, yet not so secure that it presented a real obstacle 
to government decryption.

So be careful what you ask for, those requirements were met and we've 
been living with those design decisions for so long now it's hard to 
have an objective perspective on proposed alternatives.

Who can say why one protocol is considered "secure" in its users' 
opinion? SSHv2 is a nice, cleanly designed protocol. "Why can't SSL just 
work like SSH?" they ask. Yet it's inherently vulnerable to MitM for the 
initial connection and amounts to users installing a permanent exception 
for every cert mismatch warning. The default configuration for many 
clients (including PuTTY) leaves it vulnerable to a trivial downgrade 
attack to SSHv1 which can be vulnerable to plaintext injection. These 
are known issues, but for some reason they are disregarded by those who 
like to think of SSH as some kind of gold standard.

I dislike oligarchies as much (or more) than the next guy, but IMHO we 
actually need more of it in the CA department. I don't want a big 
inclusive society of hundreds of CAs all trusted without limit by my 
browser. I personally believe the appropriate number of CAs for my 
browser is somewhere between 5 and 10. I want just enough to ensure 
reduncancy and allow for some market competition, and no more.

I may "trust" every CA approved by my browser vendor in the sense that I 
estimate with 99% probability that that CA will not act in a way which 
diminishes my effective security. But if I trust 200 of them then my 
estimation of the probability that none will fail me drops to 13% 
(0.99^200).

Of course, based on their observed performance I wouldn't trust many of 
them with a 10 foot pole. :-) Like the one with the login/password form 
on their non-SSL home page (you know who you are).

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Jul 2010 05:59:30 +0200 (MEST)

> Compared to SSL, SSH is still not popular, which sort of negates your

Quite the opposite.  Compared to SSH, SSL is a complete and utter failure.

SSH became popular in 1995 and ubiquitous on Unix platforms before 2000.

Probably >>95% of all admins of networked Unix boxes have SSH configured
and used it to access their machines remotely.  Many of them have been
doing this for >10 years.

Even lots of networked devices support SSH out-of-the-box (DSL-router,
DVB-S receiver, Home-NAS) and SSH is quite easy to configure for use
with these devices.

In comparison, the number of Web-Servers that are accessible via
SSL/TLS (HTTPS) is completely negligible.  From that fraction of
the Web-Servers that have some service running on port 443
it is around 97% that do not support SSL/TLS access.

Considering the intimidating Scare-pages of newer Web-Browsers
for Servers using self-signed certs,  the Browser-Vendors reliably
killed the usage-scenario to use TLS to access your Home-NAS,
DSL-Router or DVB-S receiver, because going through the pain
to obtain and yearly renew TLS certs for each and every device
-- in particular for the shortcut hostnames that people are
typically using at home, which most Browser-blessed CAs are
unlikely to issue certs for anyway.

The most recent developments in TLS are likely to cut back the
use of TLS to only public commercial services.  The Scare-Pages
of recent Browsers are sure killers for any intra-Home-applicability
of TLS and the standardization efforts around "server identification"
(certid) are likely to make things worse, because they are
similarly preoccupied with commercial CA certs and bureaucratic
hierarchical namespace management.

Being able to easily network a small number of computers and
network-attached devices at home without involvement of outside
third parties is a pretty common use case.  It is where SSH
started and excels in.  It is where TLS hardly worked from
the beginning and where it has become much worse since due
to the Scare-Consumers-Away-From-This-Technology pages in
recent Browsers.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Jul 2010 17:08:22 +1200

>Compared to SSL, SSH is still not popular, which sort of negates your point.

SSH has captured close to 100% of its target market.  When was the last time
you used telnet?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Jul 2010 17:11:06 +1200

Martin Rex <[email-masked]> writes:

>Being able to easily network a small number of computers and network-attached
>devices at home without involvement of outside third parties is a pretty
>common use case.  It is where SSH started and excels in.  It is where TLS
>hardly worked from the beginning and where it has become much worse since due
>to the Scare-Consumers-Away-From-This-Technology pages in recent Browsers.

+1.

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Wed, 14 Jul 2010 02:14:04 -0500

On 07/14/2010 12:08 AM, Peter Gutmann wrote:
> Robert Relyea<[email-masked]>  writes:
>

Don't get me wrong, I usually keep several SSH sessions and tunnels 
going all day long.

But I think there's still a large chunk of the "remote server 
administration" market running on RDP, VNC, Citrix, Xen, and whatever 
VMware is using for remote consoles. These all run atop TLS in the 
recommended configuration over public networks.

Popularity is a measure of something, but I'm not sure what. I am sure 
though that it's not a good measure of what I need out of my data 
security protocols.

- Marsh

---

From: Bruno Harbulot <[email-masked]>
Date: Wed, 14 Jul 2010 12:38:45 +0100

On 14/07/10 06:11, Peter Gutmann wrote:
> Martin Rex<[email-masked]>  writes:
>

Agreed, but that's comparing two different things: one is SSH, the other 
is the combination of TLS and PKIs.

I wonder how many people really check the fingerprint of the SSH server 
key when they connect to a server they haven't connected to before.

I've had warnings of key-changes by a server, for which I hadn't been 
notified of the change by the provider. After asking the technical 
customer service, it seemed that they weren't aware of the implications 
of changing the keys (I asked them what the new fingerprint was supposed 
to be but all I got was a confirmation that the key had changed, not the 
actual new fingerprint). Maybe services (for which you can't know the 
key in advance) should be encouraged to publish the fingerprints on 
their HTTPS website (whose identity will be asserted by PKIs...)

I think SSH clients do a bit better than browsers for TLS+PKI in that 
respect because the client remembers the fingerprint after the first 
connection, but apart from that, there's little to check the identity of 
the server.

PKIs aim to provide a yes/no binary answer to "can I trust this to be 
what it says it is?" (or ternary if you consider green/blue bars), only 
to abstract away the fact it's a matter of probabilities and 
risk-assessment that will end up somewhere between 0 and 1.
I'm not sure how it's possible to go further than that without providing 
users with better security education (which they don't necessarily want 
or have time to receive).

Best wishes,

Bruno.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Jul 2010 23:56:27 +1200

Bruno Harbulot <[email-masked]> writes:

>I wonder how many people really check the fingerprint of the SSH server key
>when they connect to a server they haven't connected to before.

I don't know about connecting to new servers, but if the fingerprint changes
when connecting to an existing server then the same number check it as the
number who perform out-of-band verification of certs when they change: Zero.

(I did a survey of two large .edus as groundwork for a paper I was thinking of
writing and needed to know the base rate for a fuzzy-fingerprint attack, which
allows you to spoof SSH server fingerprints unless the user methodically
verifies all 160 bits of the fingerprint.  It was zero, which meant that the
fuzzy-fingerprint attack couldn't be any worse than that.  This lead to a
proposed paper with the title "Do users check SSH fingerprints to defeat MITM
attacks?" and an abstract of "No", which I felt was brief and to the point).

This result represents good news for both the SSL/TLS PKI camps and the SSH
key-continuity camps, since SSH advocates can rejoice over the fact that the
expensive PKI-based approach is no better than the SSH one, while PKI
advocates can rest assured that their solution is no less secure than the SSH
one.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Jul 2010 15:07:51 +0300

> key when they connect to a server they haven't connected to before.

I would guess that the answer is "none". But usually, you first connect to the SSH server through a trusted connection (in the workplace, or you set it up and then connect). After that, you're good to go, and you can connect remotely.

> their HTTPS website (whose identity will be asserted by PKIs...)

Or maybe in a DNS record. And now that DNSSEC is deployed, you can use that
http://www.ietf.org/mail-archive/web/ietf/current/msg62449.html

> connection, but apart from that, there's little to check the identity of 

If browsers accepted private CAs for domain (after a one-time dialog), and self-signed certificates for a particular server only, they would get to the same level of usability and security as SSH clients. As it is, they're better if you have no way to verify the server fingerprint, and worse if you can.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Jul 2010 15:10:47 +0300

> advocates can rest assured that their solution is no less secure than the SSH

But it's kind of sad for the geek-supremacists, who would have liked to believe that geeks do security better than other people.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 15 Jul 2010 00:46:36 +1200

Yoav Nir <[email-masked]> writes:

>But it's kind of sad for the geek-supremacists, who would have liked to
>believe that geeks do security better than other people.

Geeks do security for geeks, not for other people.

(Technically they often don't even do security for geeks but for an abstract
model of how they expect other geeks to behave.  I'm not sure that DSM-IV
299.80 was actually intended to be used as a blueprint for your user model
though).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 15 Jul 2010 00:55:11 +1200

Yoav Nir <[email-masked]> writes:

>If browsers accepted private CAs for domain (after a one-time dialog), and
>self-signed certificates for a particular server only, they would get to the
>same level of usability and security as SSH clients. As it is, they're better
>if you have no way to verify the server fingerprint, and worse if you can.

In terms of securing access to local embedded devices and whatnot, there's a
relatively simple solution that'll get rid of a majority of problems in the
case of Martin's "Being able to easily network a small number of computers and
network-attached devices at home without involvement of outside third
parties":

  [...]

  Sometimes it may be possible to reach a compromise between security and
  functionality, as Microsoft did with the Windows firewall settings when they
  turned it on by default in Windows XP SP2.  Once they.d enabled it they
  found that small home networks, where some designated computer acts as a
  file and print server, were broken by having all ports on the server closed
  by default. The fix was to open the ports required for print and file
  sharing, but only for the local subnet [42].  Since home users are unlikely
  to be running computers on multiple subnets and anyone sophisticated enough
  to be doing so will presumably know what a firewall is and what to do with
  it, this protected home users from Internet-based attacks without breaking
  their existing network setup.

  [...]
  
  A far better solution though is to take advantage of the special
  circumstances in which these certificates are encountered.  If you run into
  such a duplicate certificate and it.s associated with something that has a
  non-routable IP address, or on the default gateway, or in the same subnet,
  then there.s a good chance that the certificate has been generated by a an
  embedded device rather than being some form of spoofing attack, a variation
  of the approach that Microsoft took with the Windows firewall that.s
  discussed in [text from above].  Another way of looking at this concession
  in the direction of practical usability is that if there.s an active
  attacker sitting inside your firewalled private subnet performing MITM
  attacks on you then you have far bigger things to worry about then a case of
  potential certificate spoofing.  While this adaptation won.t address every
  case of non-commercial certificate use it will transparently deal with the
  large majority of them.

Peter.

---

From: Bruno Harbulot <[email-masked]>
Date: Wed, 14 Jul 2010 15:04:35 +0100

> http://www.ietf.org/mail-archive/web/ietf/current/msg62449.html

I wonder if PKIX certificates in RFC 4398 [1] also need to be verified 
using a trust-anchor in the browser (for HTTPS). I suppose getting those 
records via DNSSEC should be sufficient (if one chooses to trust the 
DNSSEC records more than a PKI, or use DNSSEC as a form of PKI).

I also wonder if there this specification couldn't be improved by:
  - having a "raw" public key entry instead of requiring a certificate 
(DNSSEC would effectively do the certification), for SSH for example.
  - adding a port number/usage indicator to the certificate in the 
record (the public key or PKC could be different depending on the service).

Best wishes,

Bruno.

[1] http://tools.ietf.org/html/rfc4398

---

From: Robert Relyea <[email-masked]>
Date: Wed, 14 Jul 2010 10:18:40 -0700

> SSH has captured close to 100% of its target market.  When was the last time
I agree, so has SSL for it's target market. It's just that SSL's target
market is larger. The number of people doing e-commerce versus the
number of linux admins;).

bob

---

From: Marsh Ray <[email-masked]>
Date: Wed, 14 Jul 2010 12:33:30 -0500

Personally, I am not a believer in using either source or dest IP 
address as a basis for authentication. DHCP, ARP, DNS, and IP routing 
can be owned all the time. For mobile WiFi devices the default 
assumption has to be that they are always operating on untrusted networks.

DNS rebinding, connection string, and other attacks let bad guys make 
connections out from your 'internal' systems. Not to mention the 
possibility that there is at least one owned PC behind your firewall.

On 07/14/2010 07:55 AM, Peter Gutmann wrote (or maybe was quoting):
>
> Another way of looking at this
> concession in the direction of practical usability is that if there.s
> an active attacker sitting inside your firewalled private subnet
> performing MITM attacks on you then you have far bigger things to
> worry about then a case of potential certificate spoofing.

Really? Most of these attackers and botnets seem to be after your online 
banking credentials (which could easily be obtained by cert spoofing 
after compromising your home router). Which is not to say you're not 
totally owned of course, but there's no reason to that cert attacks are 
inherently less important.

This common reasoning is also a bit fallacious: SSL/TLS+PKI is supposed 
to be the thing that protects you from compromises in routing and DNS so 
it's not a straightforward comparison of the severities of the two types 
of compromise. The DNS and IP guys used to think "well they have SSL, 
SSH, and IPSEC to protect against that" so no part of the design of 
those protocols can count on anything about the lower layers.

http://www.networkworld.com/news/2010/022010-chuck-norris-botnet-karate-chops-routers.html 
:
vvvvvvvvvvv
> A D-Link spokesman said he was not aware of the botnet, and the
> company did not immediately have any comment on the issue.
>
> Like an earlier router-infecting botnet called Psyb0t, Chuck Norris
> can infect an MIPS-based device running the Linux operating system if
> its administration interface has a weak username and password, he
> said. This MIPS/Linux combination is widely used in routers and DSL
> modems, but the botnet also attacks satellite TV receivers.
^^^^^^^^^^^^^^^

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Jul 2010 20:00:31 +0200 (MEST)

Robert Relyea wrote:
> > SSH has captured close to 100% of its target market.
> > When was the last time you used telnet?

100% agreement.

> number of linux admins;).

TLS might be considered successful, when port 80 of >90% e-commerce sites
will return a simple Warning Page that one should not use HTTP
or (more conveniently) a redirect to HTTPS.

The current use of HTTPS is marginal at best for e-commerce sites,
and this is particularly embarrassing for high-profile e-commerce
such as financial e-commerce (banks,brokerage).

If I try https://www.ebay.com or https://www.ebay.de it gives
me a "connection refused".  And when I try "https://www.amazon.com"
it redirects me to "http://www.amazon.com".  So much for the success
of TLS in it's target market.
(Curiously, https://www.amazon.de remains on HTTPS -- make me wonder
 wether one of them is non-intentional and which of them).

-Martin

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 14 Jul 2010 16:49:45 -0600

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
> Sent: Wednesday, July 14, 2010 11:01 AM
> 
> Robert Relyea wrote:
> >

Haven't worked in a bunch of enterprises with lots of legacy Unix equipment around huh?  Or with terminal servers, weird SAN hardware, etc. have you...

> will return a simple Warning Page that one should not use HTTP or (more
> conveniently) a redirect to HTTPS.

Wait, so the protocol is only successful when people adopt it for the purposes you want them to?  I'm not sure I get this. It isn't like those sites went with an alternative web encryption protocol right?  It isn't like TLS is a failure because they chose something else, it is because they decided they didn't want to use TLS/SSL.  

> The current use of HTTPS is marginal at best for e-commerce sites, and this is
> particularly embarrassing for high-profile e-commerce such as financial e-
> commerce (banks,brokerage).

Actually, I think that the recent work that the Google guys did - http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html - might have some impact on this.  There is some cost to using TLS.   

By way of reference - there are still tons of people running FTP rather than using FTPS or SFTP for all of their file transfers.  Why?  Because it is way faster in most cases.  I think this is better comparison to the HTTP vs. HTTPS debate.  There is still a TON of FTP out there because it has a lot of nice performance characteristics.   And, people aren't willing to get rid of it in lots of cases because of that.  Using SFTP to transfer very large files is painfully slow in comparison.

--
Andy Steingruebl

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 15 Jul 2010 18:52:28 -0700

> SSL is designed to allow you to make secure connections for the masses.

Note that I'm writing this as a reply to Martin, but not directly *to*
Martin.  This is a major issue that I'm seeing, going through the archives.

TLS has several modes which are unsupported by the members of this list:

1) A supported (by the standard) mode of "unauthenticated TLS" (neither
the server nor the client offer or demand certificates).
2) Mutual Authentication -- it's supported by this group in the
protocol, *except* that very few clients who actually have certificates
typically don't have the marketing acumen to show just why they might be
useful.
3) The classic "server authenticates, client doesn't" issue -- which
relates to the massive "secure renegotiation" effort which could have
been avoided had the TLS group coordinated with the PKIX group to figure
out how to increase the use of initial-mutual-authentication -- and
which would, at the least, require the PKIX group to realize that the
adoption rate for publicly-useful (i.e., issued by publicly-recognized
CAs) identity certificates is so low that their specification for them
just happens to be useless for the Internet PKI, instead being useful
only for the Corporate PKI.
4) There is a mode which is starkly, abjectly forbidden by the TLS
specification (if the 'server' does not authenticate to the 'client',
then any request by the 'server' for the 'client's certificate is closed
with an unexpected_message alert.)  I find it telling that the last time
I brought this issue up, someone had the gall to suggest "well, in your
application, just tell the connecting process that it's the server."  I
shouldn't have to, and the fact that a programmer must initiate a
workaround means that it's a bug in the protocol.  (Among other things,
Nelson Bolyard said, when I mentioned implementing it, "That wouldn't be
TLS, that'd be "Kyle Hamilton's TLS-like protocol".)

You can place the blame for the failures of PKIX on the PKIX Working
Group -- but you can't shift the blame for fact that you're forcing
implementors to essentially create "the TLS-based protocol that has the
property that the connector sends its certificate first" if they want to
have their software use the same semantics that ipsec has had since its
inception.

Robert, you're right -- today's browsers no longer raise pop-up
windows.  Instead, they take you to a scary page that gives options to
either "get me out of here" or "pop up the scarier window".  This is a
step *backwards* in usability.

From my NPOV over the last 5 years that I have archives I can reach only
a trio of conclusions: TLS WG has failed.  PKIX WG has failed. IPsec WG
has failed.  And the reason for the failures has nothing to do with the
quality of the work put out -- TLS WG, in particular, has done amazing
things with what it's been given -- but because a system cannot be put
together without a holistic, full-system integration of security,
according to the policies which must be implemented (and which are *NOT*
the purview of the protocol working group to pretend to know about ahead
of time).  These three WGs have failed to work together, and have failed
to come up with a useful, usable, and interoperable infrastructure that
grants maximum choice to the actual end-administration implementor. 
(Preferably with preconfigured "best practices" options, for different
environments.)

There's few, if any, "Best Practices" that have come out of any of these
three groups -- all that have come out have been either Informational or
Standards-Track RFCs.  The last time I saw anything informational come
out of the PKIX group, it was in order to put out a framework for
guiding the creation and auditability of Certification Practice
Statements and Certificate Policies -- which, by the way, doesn't
provide ANY guidance to any sysadmin.

I'll note, just for reference, and only because I did the count:

X.509:08/2005 is 174 pages long, including 39 pages of text that is not
characterized as being contained within any RFC ('non-normative annexes'
and the roman-numeral pages at the beginning, a blank page, and the
title page).  That's 135 pages of actual normative content.

RFC 5280, on the other hand, is 152 pages.  This means... THE NORMATIVE
INTERNET PROFILE FOR X.509 IS LARGER THAN NORMATIVE X.509 ITSELF.  This
is as close to 'insane' as I can find myself thinking about standards
bodies (in this case, the PKIX WG).

Please.  Find a way to interact more with the other working groups that
also use PKIX.  Find a way to create a less-haphazard security
infrastructure.  Find a way to let either end "elect" to provide its
certificate first, regardless of what role (listener/server or
connector/client) it thinks it is.  And find a way to let either end
"elect" to request a certificate first.

VNC paved the way for a new connection paradigm: let the server contact
the client, and then the client acts as a client and the server acts as
a server.  This was typically useful for situations where there's no
outbound firewall but there is an inbound firewall.

So why can't we set something up like that?  This would create something
like the "push server" concept (remember 1995, how that was going to be
the next big thing?  It got supplanted by RSS, then ATOM), but we also
have teredo IP NAT traversal nowadays so we can have peers behind
firewalls talking with each other.

(Granted, I'd rather teredo wasn't necessary, and I'd prefer that
everyone move to IPv6.  But still, we need to convince the US ISPs that
IPv6 is actually necessary.)

-Kyle H

---

From: Marsh Ray <[email-masked]>
Date: Thu, 15 Jul 2010 22:58:09 -0500

> the server nor the client offer or demand certificates).

I for one fully support the use of anon-anon TLS, as long as its 
limitations are clearly understood by those using it.

> typically don't have the marketing acumen to show just why they might be

I fully support the use of client certs. I think they're great and use 
them in several production contexts.

> out how to increase the use of initial-mutual-authentication -- and

Renegotiation needed to be saved, not abandoned. Some important non-web 
systems depended on it, like Tor.

> only for the Corporate PKI.

Maybe I don't have a very good imagination, but I can't think of a lot 
of places on the net I'd really want to strongly authenticate to with my 
photo ID and US passport class of identity. When I occasionally buy 
something online the merchant and card network are more interested in 
authenticating the card than cross referencing my own identity. And for 
everything else I prefer casual, weakly authenticated accounts with 
throwaway usernames.

> with an unexpected_message alert.)

It does seem rather asymmetric. For the current protocol design I 
suspect it wouldn't be secure for the client to validate with his 
certificate to an anonymous party, he could be subject to credentials 
forwarding attacks. Maybe a protocol extension could support it, but 
it'd take a lot of work to prove it's secure and there doesn't seem to 
be a huge demand for it.

> I find it telling that the last time

Here's what the spec says:
>    client
>        The application entity that initiates a TLS connection to a
>        server. This may or may not imply that the client initiated the
>        underlying transport connection. The primary operational
>        difference between the server and client is that the server is
>        generally authenticated, while the client is only optionally
>        authenticated.
>    server
>        The server is the application entity that responds to requests
>        for connections from clients. See also under client.

I don't see anything wrong with it.

The true abomination is optional STARTTLS. Anybody catch my blog post 
about just how eager Mozilla Thunderbird is to give my plaintext 
password to an anonymous TCP server?
http://extendedsubset.com/?p=22

> have their software use the same semantics that ipsec has had since its

IMHO, one can't implement something truly interesting without pushing 
the boundaries a little bit and putting up with the inevitable criticism 
from those who are (perhaps legitimately) concerned that you're on 
untested ground. But really that's nothing compared to the criticism 
you'll get if you bend the rules and the result turns out to suck.

> step *backwards* in usability.

I don't want usability for the broken cases.

> (Preferably with preconfigured "best practices" options, for different

I'll buy that. I've been studying TLS pretty intensively over the last 
year and I feel like I've learned next to nothing about PKIX and IPsec.

> provide ANY guidance to any sysadmin.

Right. My sense is that the mission of these WGs is to ensure that the 
wire protocols perform as advertised and interoperate well and evolve in 
an orderly fashion. That's enough of a challenge that I don't see 
anything wrong with stopping there.

> bodies (in this case, the PKIX WG).

I bought these thick books about the implementation of IPv6, 2000 pages 
down to the source code and everything. Can you guess how many pages 
were about security? About 80 (the last chapter of the last book).

> infrastructure.

The public, commercial PKI sucks. Increasingly, influential people in 
the data security field believe it's time for this to change, and it 
will, once it really sinks in to people just how screwed they are.

My advice to the current CA industry is to lead or follow. It will not 
occur to anyone to ask them to get out of the way once they drift past 
the event horizon of the black hole of irrelevance.

> Find a way to let either end "elect" to provide its

That's incredibly difficult to do well in a protocol because it's 
inherently vulnerable to downgrade attack. Encryption is useless without 
authentication (in the presence of an active attacker). When the 
authenticated parameters are negotiated, the attacker gets to pick the 
weakest authentication methods compatible with each endpoint.

For example, what stops bad guy from telling the server he doesn't want 
a certificate - and telling the client the same thing in the other 
direction? There are solutions to this, but they generally involve more 
round trips, trusted 3rd parties, and/or additional work on the part of 
the appliction code. Considering the success rate apps have in 
implementing the current server cert checking properly it may be a 
little optimistic that they would get a negotiated authentication scheme 
secured very often.

> outbound firewall but there is an inbound firewall.

Yeah that's handy. I also tunnel stuff around with SSH a lot.

> firewalls talking with each other.

By and large, people don't want their systems exchanging connections 
freely with external systems. That's how the internet was originally 
designed, but that design has been flatly rejected. There are likely far 
more home and office routers doing NAT than straight internet routers. 
AFAICT, only SMTP and the core routing protocols still work that way. IP 
source routing - gone. FTP - passive mode only. Games and IM go through 
backend servers and P2P file sharing runs in degraded mode without 
special exceptions.

If you want to make a new protocol today, the key is flexibility. The 
endpoints need to appear to the transport layer as client or server as 
necessary. Even big guys like Microsoft have largely given up on making 
anything new that doesn't tunnel over HTTPS on TCP port 443.

But even outgoing connections are increasingly filtered. Deep packet 
inspection gear is even MitMing TLS connections by forcing installation 
of a trusted root cert on every client. It's probably only a matter of 
time before some vendor buys themselves a trusted root or intermediate 
signing key, if that hasn't happened already.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 16 Jul 2010 16:08:23 +1200

Kyle Hamilton <[email-masked]> writes:
>3) The classic "server authenticates, client doesn't" issue 

Just to be pedantic, what you're describing in (2) isn't mutual authentication 
but unilateral authentication in both directions, which is just as phishable 
as (3) is.  Real mutual authentication is TLS-PSK and TLS-PSK.

>bodies (in this case, the PKIX WG).

Not only that, but the PKIX standing committee has so far produced one 
thousand seven hundred pages of PKI standards with a further five hundred 
pages of additional draft standards waiting in the wings. Just to put that 
into perspective, this means that one single PKI committee's standards and 
drafts are more than twice as voluminous as all three volumes of Stevens' 
TCP/IP Illustrated, which covers not only all of the core protocols used on 
the Internet (in far more detail than the RFCs do) but contains a complete 
implementation of a TCP/IP protocol stack to boot.

(I'm sure there's some sort of standardisation variant of "a country was never 
taxed into prosperity" lurking in there, but the few variants I can think of 
don't sound like much).

Peter.

---

From: Bruno Harbulot <[email-masked]>
Date: Fri, 16 Jul 2010 18:19:06 +0100

On 16/07/10 05:08, Peter Gutmann wrote:
> Kyle Hamilton<[email-masked]>  writes:

Sorry if I don't quite understand, but could you clarify what you mean 
by phishable, and what the issue is?

Best wishes,

Bruno.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 20 Jul 2010 00:44:01 +1200

Marsh Ray <[email-masked]> writes:

>1. Is TLS an effective and secure cryptographic protocol primitive? Does it
>deliver on the stated and implied guarantees given by its RFCs?

This is an interesting issue, I'm not sure if there actually is any document
that covers the TLS threat model apart from Ian Grigg's wonderful definition
of the "the threat model is whatever the protocol is capable of defending
against".  In the DNSSEC case it wasn't until ten years after the initial
DNSSEC RFCs were published that someone sat down and documented what it was
that they were trying to achieve (!!!).  What we'd need here is a clear
statement of what TLS can, and can't, protect against, and under which
circumstances, and in which configurations.  Until we have that baseline to
build on, it's (unfortunately) not really possible to have a meaningful debate
about whether it meets is goals because we don't know if aspect X is a flaw in
TLS, a flaw in something other than TLS, not a flaw at all, or out of scope.
As Bob Morris once said [0], "the behaviour of a program withot a
specification can never be wrong, merely surprising".

Peter.

[0] I'm not certain that he was the person who said this, if anyone knows
    who it was, and where, could they let me know.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 19 Jul 2010 17:12:15 -0500

On 07/19/2010 07:44 AM, Peter Gutmann wrote:
> that covers the TLS threat model  [...]
>   What we'd need here is a clear

This sounds like an endeavor of great merit.

Is this the type of project that any other [TLS] members would be 
interested in collaborating on? The result could be submitted as an 
informational RFC or, at the very least, we might end up with a set of 
wiki pages somewhere. This could cut down on some of the repetitive 
debate that shows up on this list from time to time. It could also be a 
good student project.

Ivan Ristic started addressing it from a pretty high level:
http://blog.ivanristic.com/2009/09/ssl-threat-model.html

Firstly, we'd need agreement on which RFCs were in scope for the 
project. Is this already documented somewhere for the list charter?

Since TLS has so many negotiable parameters and extensions, it might be 
a little difficult to structure it as a flat document. Does anyone have 
suggestions on how to organize it considering all the cipher suites, 
authentication modes, extensions, etc.?

> specification can never be wrong, merely surprising".

And it tends to consume a lot of unnecessary discussion precisely at the 
time of the "surprise" when coordination is needed for incident response.

What would be really great is when the next big "reverse quadrangle 
padding interpolation attack" is published, we had something ready which 
could help enumerate all the design features which had built on the 
specific properties that had been violated.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Jul 2010 01:12:12 +1200

>This sounds like an endeavor of great merit.

Phew, that's better than "OK, you write it then" :-).

(This would also be useful for the rest of the big 5, IPsec, SSH, S/MIME, and
PGP, for which the threat model is mostly "here's what we defend against, if
that's what you want then use it").

>Is this the type of project that any other [TLS] members would be interested
>in collaborating on?

Count me in.

>http://blog.ivanristic.com/2009/09/ssl-threat-model.html

That's a good start, I was thinking of something vaguely similar but built
more around services that people require, so providing a shopping list like
confidentiality, integrity, dispute (what's incorrectly referred to as
"nonrepudiation" most of the time), availability, and so on, and then listing
under which conditions TLS does and doesn't provide this.  It depends on what
the target audience is, Ivan's attack tree is for people worried about how TLS
might fail while the services-provided categorisation is for people who need a
particular service from TLS and want to know whether they're getting it.

>Firstly, we'd need agreement on which RFCs were in scope for the project. Is
>this already documented somewhere for the list charter?
>
>Since TLS has so many negotiable parameters and extensions, it might be a
>little difficult to structure it as a flat document. Does anyone have

I think for the services-provided approach it might be feasible, so you could
say, for example, that "basic TLS doesn't provide this, but with the XYZ
capability present it provides a subset of this", that sort of thing. Actually
this works for the attack-tree approach as well, a particular arc would be
"unmitigated by basic TLS, mitigated by XYZ".

(I'm not saying the services-provided view is the best one, it could quite
well be terrible, I'm just throwing it out there as a possibility).

>What would be really great is when the next big "reverse quadrangle padding
>interpolation attack" is published, we had something ready which could help
>enumerate all the design features which had built on the specific properties
>that had been violated.

Yup.  What I'd be aiming at is, cheating a bit and using some secure logging
text I have lying around as an example, that a user reading the document
wouldn't end up with a generic "audit data is stored in a secure manner"
(secure relative to what?) but more something like "audit data is stored in a
file only writeable by the system-audit user. It should be secure from
tampering provided that the operating system file protection mechanisms are
functioning as intended, that the system-audit user account hasn.t been
compromised, and that the security of the operating system itself hasn.t been
compromised, for example through a rootkit that can override the security
mechanisms of less-privileged system components".

Peter.

---

From: Ralph Holz <[email-masked]>
Date: Wed, 21 Jul 2010 15:23:18 +0200

Hi,

>> Is this the type of project that any other [TLS] members would be interested

Although I have only recently arrived on this list, I would certainly
like to follow this as well.

-- 
Best regards,
Ralph

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Jul 2010 16:25:30 +0300

> Phew, that's better than "OK, you write it then" :-).

Nah, Marsh is just being polite. You can't submit drafts right now, but we expect draft-gutmann-tls-why-00.txt early next week, so that we can all read it before the TLS WG meeting on Thursday. :-)

>> Is this the type of project that any other [TLS] members would be interested

Me too.

---

From: Nasko Oskov <[email-masked]>
Date: Wed, 21 Jul 2010 16:17:24 +0000

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
>Sent: Wednesday, July 21, 2010 6:26 AM
>
>interested

I am interested in participating as well.

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Jul 2010 21:46:18 +0200 (MEST)

> type models were simply not going to get the shoppers online.

Trust-on-first-use would have worked just fine, and would be
several magnitudes more secure than the mess there is with the
dozens of independent, pre-trusted and equivalent roots.

In case you forgot, Browsers orignally used to show a warning
popup when you switched from plain HTTP to HTTPS, and you had
to checkmarked to not see that warning anymore -- which negates
your point that trust-on-first-encounter would not have worked.

> to government decryption.

There is no need to convince people.  This is why social engineering
is so much easier and works so reliably compared to attacking
encrypted communication.

> diminishes my effective security.

The concept that you describe is commonly known as "faith".
"trust" in the security area used to have a very different meaning.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Jul 2010 23:05:08 +0200 (MEST)

Steingruebl, Andy wrote:
> 
> Actually, I think that the recent work that the Google guys did
> - http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
> - might have some impact on this.  There is some cost to using TLS.   

Of course there is some cost to using TLS, but computationally it
has been marginal for common web uses for many years.  Where you
notice it is with downloads of large amounts of data (several MBytes)
over high-speed links (100 MBit/s+), because the raw encryption
speed of the symmetric ciphers becomes visible.

The performance of TLS with software-crypto was perfectly acceptable
6 years ago on x86 and x86_64 bit Hardware platforms.  I 
All performance problem I've seen so far were the result of bugs
and software design flaws, but not problems of the technology or
lack of speed of the underlying hardware (maybe with the exception
of a few RISC-based unix boxen for which a decent crypto speed with
portable C code has been notoriously difficult to achieve).

The most difficult issue with larger servers is not the crypto,
but correct and efficient TLS session cache manangement.

And there still is a lot of (non-browser) software out there where
TLS session caching doesn't work, is defective in certain
configurations (Microsoft IIS) or is not implemented (apache mod_proxy).

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Jul 2010 17:56:05 +1200

Martin Rex <[email-masked]> writes:

>The concept that you describe is commonly known as "faith". "trust" in the
>security area used to have a very different meaning.

It's often not even faith, it's psychotic trust.  I'm not sure if there's a
specific term for this though.

Peter.

---

From: Kyle Hamilton <[email-masked]>
Date: Tue, 27 Jul 2010 13:22:35 -0700

> interested in helping, not a handful of sysadmins somewhere.

At least in the United States, VISA and MasterCard are still (and have
been for the past 8 years or so) offering $0 liability, so there's not
even a real reason to do this anymore.  (As well, there are banks that
generate one-time-use credit card numbers, that will never authorize
another transaction.)

So, really, why are we doing this again?  I mean, a whole bunch of
arguing of the politics of the situation for what is, essentially,
simply about the end-user's *convenience?*

I think we need to remember something here:  We have been arguing
about what is going to be protected for over a decade.  I think we're
looking too small, and I think that the PKIX is also looking too
small.  We're about to be assaulted and blindsided by a new set of
software working with a new set of probably-proprietary protocols, in
response to President Obama's call for technology reform in the
so-called "Identity Ecology".

> Umm... I better not reply to a statement like this, because the response would

What, that users have to be responsible for themselves and their
transactions, and thus they have to learn what tools they have
available?  They *do* play an essential role, in fact *the* most
essential role.  Without them, we have no reason to do the work we do.
 But they are, as they will always be, legally culpable for their own
actions, and so it does make sense that they understand the
consequences.

What we don't need to do is drag people through PKI 101.  I believe
it's entirely possible to implement and explain a system like this
without necessarily exposing the users to what's going on underneath.

> Steffen, you've won your prize :-).

Instead of saying something like that, how about we actually
*implement* something like that?  I found a way to do it, but it
breaks traditional X.509 path validation rules on the certificate
itself, instead applying them to X.509 attribute and/or identity
certificates contained within the certificate structure that relate to
the same key.

But, I am stuck asking... what would "first-rate support" look like?

-Kyle H