Re: [cryptography] not a Paypal phish using EV certificate

[Andy Steingruebl]

On Tue, Aug 13, 2013 at 9:25 AM, Ben Lincoln (F70C92E3) <
f70c9...@beneaththewaves.net> wrote:

>
> Unfortunately, it does look somewhat suspicious from a phishing
> perspective, especially if a link to a paypal.com subdomain redirects to
> it, which (to an end user) looks a lot like what happens when a link to a
> phishing site is disguised as a link to the real site.
>

Yep, but at the same time all links in the email point to the same domain
that the mail is from, rather than to things that aren't paypal.com which
is by design from a monitoring, control, and anti-abuse perspective.   That
way the user isn't making decisions about clicking on a link to a domain
they haven't heard of, they get routed through one they are more familiar
with.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] not a Paypal phish using EV certificate

[Andy Steingruebl]

On Tue, Aug 13, 2013 at 6:25 AM, John Levine  wrote:

> In article  you write:
> >I recently got a another of the standard phishing emails for Paypal,
> directing
> >me to https://email-edg.paypal.com, which redirects to
> >https://view.paypal-communication.com, which has a PayPal EV certificate
> from
> >Verisign.  According to this post
> >http://www.onelogin.com/a-paypal-phishing-attack/ it may or may not be a
> >phishing attack (no-one's really sure), and this post
> >http://www.linuxevolution.net/?p=12 says it is a phishing attack and the
> site
> >will be shut down by Paypal... back in May 2011.
> >
> >Can anyone explain this?
>

I'm investigating.

Definitely a PayPal domain.  Not sure why reports of it being phishing
would have been confirmed.  I've asked the right folks if there was a bug.


> I agree that it was not a great idea for Paypal to invent
> paypal-communication.com rather than a subdomain of one of their
> existing well-known domains such as communication.paypal.com.
>

An entirely separate discussion though about how one runs lower and higher
security things on the same domain given how inflexible the same-origin
policy and cookie policies are.I agree these are tricky, but putting
everything on one domain is tricky as well...

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Which CA sells the most malware-signing certs?

[Andy Steingruebl]

On Mon, Feb 18, 2013 at 7:07 AM, Peter Gutmann wrote:

> I've just done a quick tally of the certs posted to
> http://www.ccssforum.org/malware-certificates.php, a.k.a. "Digital
> Certificates Used by Malware".  Looks like Verisign (and its sub-brand
> Thawte)
> are the malware-authors' CA of choice, selling more certs used to sign
> malware
> than all other CAs combined.  GeoTrust comes second, and everything below
> that
> is in the noise.  GoDaddy, the most popular CA, barely rates.  Other CAs
> who've sold their certs to malware authors include ACNLB, Alpha SSL (which
> isn't supposed to sell code-signing certificates at all as far as I can
> tell),
> Certum, CyberTrust, DigiCert, GeoTrust, GlobalSign, GoDaddy, Thawte,
> StarField, TrustCenter, VeriSign, and WoSign.  Everyone's favourite
> whipping-
> boy CAs CNNIC and TurkTrust don't feature at all.
>

Any sense of how many of these we used by the "owner" to sign malware and
how many were stolen?

Would be nice to know what we think this is measuring...
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Gmail and SSL

[Andy Steingruebl]

I think what you really want is the ability within Google's interface to
specify how you'd like the certificate verified.  If the threat model they
are defending against is MiTM, then merely accepting the certificate
without prompting from you provides protection against passive
eavesdropping only, not active MiTM.  They've chosen to try and defend
against those who can tinker with packets, not just observe them.

You may disagree that this is the right threat to protect against (you
might be more worried about the NSA observing packets for example, rather
than tinkering with them) but given some of the more recent attacks against
Google (and Facebook's) customers they believe that active MiTM is actually
a real threat, and would rather not pretend to protect you from it when
they aren't, by using a self-signed certificate that they haven't verified
in any way, even by you presenting it.

The obvious solution is to either:

1. Not use TLS
2. Default to CA signed certificates
3. Support other protocols or means for you to identify what keys and/or
trust-anchors you trust.

Given that Google actually controls the client-code in this case, it might
actually a truly usable use-case for the newly minted CAA and TLSA (DANE)
specifications.  They can't be deployed most places (browsers) because of
last-mile DNS tinkering by all of the middleboxes on people's networks, but
that probably isn't the case where Google is connecting to your server,
using theirs.

Just a thought.

- Andy



On Fri, Dec 14, 2012 at 7:51 AM, Eugen Leitl  wrote:

> - Forwarded message from Randy  -
>
> From: Randy 
> Date: Fri, 14 Dec 2012 09:47:03 -0600
> To: NANOG list 
> Subject: Gmail and SSL
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
> rv:17.0) Gecko/17.0 Thunderbird/17.0
>
> I'm hoping to reach out to google's gmail engineers with this message,
> Today I noticed that for the past 3 days, email messages from my personal
> website's pop3 were not being received into my gmail inbox. Naturally, I
> figured that my pop3 service was down, but after some checking, every thing
> was working OK. I then checked gmail settings, and noticed some error.
> It explained that google is no longer accepting self signed ssl
> certificates. It claims that this change will "offer[s] a higher level of
> security to better protect your information".
> I don't believe that this change offers better security. In fact it is now
> unsecured - I am unable to use ssl with gmail, I have had to select the
> plain-text pop3 option.
>
> I don't have hundreds of dollars to get my ssl certificates signed, and to
> top it off, gmail never notified me of an error with fetching my mail. How
> many of email accounts trying to grab mail are failing now? I bet
> thousands, as a self signed certificate is a valid way of encrypting the
> traffic.
>
> Please google, remove this requirement.
>
> Source:
>
> http://support.google.com/mail/bin/answer.py?hl=en&answer=21291&ctx=gmail#strictSSL
>
> - End forwarded message -
> --
> Eugen* Leitl http://leitl.org";>leitl http://leitl.org
> __
> ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
> 8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] DKIM: Who cares?

[Andy Steingruebl]

On Fri, Oct 26, 2012 at 2:27 AM, ianG  wrote:

>
>> - It probably wasn't an accidental mis-config, because it's unlikely that
>> a
>>pile of major organisations would all make the same config mistake.
>>  Look at
>>SSL, the exact same organisations have no problem using strong SSL
>> keys, but
>>the same thing with DKIM uses weak keys.
>>
>

Tools like Ivan Ristic's SSL Labs (https://www.ssllabs.com/) have done
wonders for those wishing to make sure they have configured their HTTPS
webservers correctly.

You'll notice that similarly easy to use tools for other systems employing
cryptography aren't what I'd call abundant.


>> That means there was probably some business, legal, or social reason why
>> this
>> occurred.
>>
>
I expect initially, yes.  Afterwards though I think a lack of easy to use
tooling and monitoring tools is more to blame than anything.

In the HTTPS world it is almost always the case that the organization that
generates and manages the keys also manages/runs the webserver.

In the email world you'll find that with the amount of outsourcing to ESPs
the same thing isn't true.  This makes DKIM more operationally complex than
HTTPS.  Not unbearably mind you, but definitely more complex.


- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] trustwave admits issuing corporate mitm certs

[Andy Steingruebl]

On Sat, Feb 25, 2012 at 4:54 PM, Marsh Ray  wrote:

>
> Still it might be worth pointing that if Wells Fargo really wanted to
> forbid a Trustwave network-level MitM, SSL/TLS provides the capability to
> enforce that policy at the protocol level. They could configure their web
> app to require a client cert (either installed in the browser or from a
> smart card).
>
>
Maybe though you meant this specific type of "non-malicious" MiTM and the
problem is we don't have a name for that right now.

If you meant all MiTM though, your solution only only stops attackers who
wants to make it look like you're interacting with the real site, not one
who merely wishes to steal your data.  In that case they don't have to talk
to the real wells-fargo website :)

This is exactly why some people are pushing so hard for protocols that get
"exclusion" including things like CA-Pinning in Chrome, CAA, etc...

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Chrome to drop CRL checking

[Andy Steingruebl]

On Tue, Feb 7, 2012 at 6:05 AM, Marcus Brinkmann <
marcus.brinkm...@ruhr-uni-bochum.de> wrote:

>
>>
> That's a false dilemma.  You could also extract trust from your cache, ie
> your past experience with the same server (the SSH model), and/or from your
> past connections with the internet (CRL or monitoring servers differently
> from Google Chrome autoupdater).
>
> Langley doesn't state why he is limiting the options in this way.  It is
> probably a mix of cultural bias and technical reasons (performance, etc).
>
> In any case, the proposal still keeps an old-fashioned CRL around to check.
>
> Later on, Langley seems to want to replace the CRL with a positive proof
> of freshness:
>
> http://www.imperialviolet.org/**2011/11/29/certtransparency.**html


You do realize that there is a lot of work going on in parallel to fix all
of this, and the current CRL distribution is yet one of many things they
are likely exploring, right?

I don't remember Adam saying in his blog post or in any other posts, etc.
 that this is the only change they will make to Chrome.  At the same time I
think they did get fairly tired or hard-coding a CRL list into the Chrome
binary itself for the CA breaches...

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[Andy Steingruebl]

On Mon, Sep 19, 2011 at 9:42 AM, Marsh Ray  wrote:
>
> I love SSH and think it's a great protocol. But to be honest, we have to
> admit that it would be far worse than SSL at the problem
> no-prior-relationship ecommerce bootstrapping problem.

Yes, it probably is worse at that.  That said, it did an amazing job
at stopping all of the passive password sniffing that went on when it
was first released.  Our compromised accounts where I worked at the
time went down insanely when we switched over to SSH for logins.
People at the time weren't performing MiTM attacks, they were "just"
sniffing, and SSH totally defeated that.

Was it a failure because it didn't solve bootstrapping perfectly, it
didn't have a perfect UI, etc?  Nope, it wasn't.  It was pretty
upfront about the types of errors that could occur.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[Andy Steingruebl]

On Sun, Sep 18, 2011 at 2:01 PM, James A. Donald  wrote:
>
> SSL fails at low security stuff in that it allows phishing,


You know what else fails at fighting phishing?

- The locks on my car door
- The fence surrounding my house
- The full disk encryption on my laptop



SSL wasn't designed to stop phishing, if sites don't deploy it with
mutual-auth it can't possibly do so.  Saying it is a failure because
it doesn't stop that ignores the problem it is designed to solve, or
at least some it could credibly claim to solve.

SSH doesn't solve phishing either.  Is it a total failure also?  I
don't think so.

SSL is used for a lot more than HTTPS.  Any proposal to "fix" it
*must* take that into account.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Let's go back to the beginning on this

[Andy Steingruebl]

On Wed, Sep 14, 2011 at 7:34 PM, Arshad Noor  wrote:
>
> However, an RP must assess this risk before trusting a self-signed
> Root CA's certificate.  If you believe there is uncertainty, then
> don't trust the Root CA.  Delete their certificate from your browser
> and other applications, effectively removing all risk from that CA
> and its subordinates from your computer.  Or, choose not to do
> significant business over the internet when you see their certificate
> on a site - you always have the choice.

1. You don't really always have a choice.  Many devices such as
smartphones don't allow you to edit the trust-store.
2. Not everything that uses TLS has a user interface to the TLS
connection information, information about the CA, cert-chain, etc.
For example, most/all email clients that do IMAPS don't let you even
see who the CA is, set rules, modify the keystore, etc.

Not everything online is a web browser, and some good chunk of the
problem we have here can't be even partially mitigated even by experts
because the software doesn't have those controls, even when it is a
web browser.  Please go ahead and examine the CA and cert-chain when
you are using HTTPS within mobile safari :)

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Let's go back to the beginning on this

[Andy Steingruebl]

On Tue, Sep 13, 2011 at 4:09 PM, Ralph Holz  wrote:

> Well, yes, but it is the Alexa Top 1 million list that is scanned. I can
> give you a few numbers for the Top 1K or so, too, but it does remain a
> relative "popularity".

How many of those sites ever "advertise" an HTTPS end-point though?
Maybe users are extremely unlikely to ever see a link, etc. that
points to their HTTPS endpoint.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Let's go back to the beginning on this

[Andy Steingruebl]

On Tue, Sep 13, 2011 at 3:42 PM, Ralph Holz  wrote:
>
> That said, I can see in our monitoring data that about 20-60% of
> certification chains are broken, and these are sites that people do
> access (it is passive monitoring data from a large regional ISP).

Interesting.  Are you pulling the server-certs out of the SSL
handshake and then checking if they validate against any browser
store?

> In our scanning data, we find that only about 18% of certificates have
> both a valid chain plus the correct hostname (wildcarded or not) in
> their CNs or SANs.

This data, while interesting, doesn't tell us much about how often
users encounter those sites.  I much prefer data instrumented from
actual web browsers, or network traffic.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Let's go back to the beginning on this

[Andy Steingruebl]

On Tue, Sep 13, 2011 at 10:48 AM, Steven Bellovin  wrote:

> Furthermore,
> they're probably right; most of the certificate errors I've
> seen over the years were from ordinary carelessness or errors,
> rather than an attack; clicking "OK" is *precisely* the right
> thing to do.

Is anyone aware of any up-to-date data on this btw?  I've had
discussions with the browser makers and they have some data, but I
wonder whether anyone else has any data at scale of how often users
really do run into cert warnings these days. They used to be quite
common, but other than 1 or 2 sites I visit regularly that I know ave
self-signed certs, I *never* run into cert warnings anymore.   BTW,
I'm excluding "mixed content" warnings from this for the moment
because they are a different but related issue.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] wont CA hackers CA pin also? and other musings (Re: PKI "fixes" that don't fix PKI (part III))

[Andy Steingruebl]

On Sun, Sep 11, 2011 at 8:37 AM, Douglas Huff  wrote:
>
> On Sep 11, 2011, at 9:25 AM, Thierry Moreau wrote:
>>
>> E.g. http://datatracker.ietf.org/wg/dane/ (DNS-based Authentication of Named 
>> Entities (dane))
>
> Which makes a huge assumption about DNS SEC that is just not realistic. 
> Namely, the one I just mentioned, that end clients would actually be 
> validating. Meaning that the MITM I mentioned becomes hilariously effective 
> in the vast majority of scenarios where the clients themselves are not doing 
> the validating. Giving a nice illusion of additional verification with no 
> substance.

It doesn't make that assumption at all, and way too many cycles were
spent going over this problem repeatedly.  All of the discussion has
essentially required the client to end-to-end verify the answer, which
given the amount of network breakage in the world that makes this
difficult, is a serious wrinkle in attempts to deploy solutions like
this.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Diginotar Lessons Learned (long)

[Andy Steingruebl]

On Sun, Sep 11, 2011 at 10:45 AM, Peter Gutmann
 wrote:
> "James A. Donald"  writes:
>>On 2011-09-11 9:10 AM, Andy Steingruebl wrote:
>>> 1. Phishing isn't the only problem right?
>>> 2. To some degree this is a game where we have to guess their next
>>> step, and make that harder too.
>>
>>If we were doing something about their first step, then it would be necessary
>>to guess their next step.
>
> My point exactly.  We can start debating what type of lock to put on the barn
> door once we add a door.

Several things already in place and/or in progress:

1. DKIM

2. ADSP (or replacement)

3. Email security indicators research - do they help, hurt, or do
nothing. I don't think existing work on other browser security
indicators aren't perfectly relevant in this space.  For an example of
what I mean -  http://www.iconix.com/ , but both Google and Yahoo have
experiments that are similar.

4. Non-stealable "credentials". A much longer/harder problem.

Even with these of course attackers can steal other things of value...
 That said, I think phishing against some folks is actually in serious
decline, and we're pushing the attackers away from phishing and
towards other things.  Data is of course notoriously hard to get on
this front.

BTW, lest you be confused about some other reported metrics, check
here: 
http://www.thesecuritypractice.com/the_security_practice/2011/02/phishing-metrics-demystified.html

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] PKI "fixes" that don't fix PKI (part III)

[Andy Steingruebl]

On Sat, Sep 10, 2011 at 4:46 PM, John Levine  wrote:
>
> But Steve, generic malware runs on your PC or in your browser.  If
> they wanted to steal card numbers, they'd steal card numbers today,
> from the browser or by key logging, before the numbers got TLS-ed.
> Since they don't do it now, I don't see any reason to think they'd do
> it if it were easier to steal them other places.

Do you have any data to support your assertion that malware isn't
stealing credit card numbers from individual PCs?

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Diginotar Lessons Learned (long)

[Andy Steingruebl]

On Sat, Sep 10, 2011 at 4:01 PM, Peter Gutmann
 wrote:
>
> Sure, figuring out whether it'll actually work is an experiment.  OTOH we have
> vast masses of data on what phishers are doing, so while we can't easily tell
> what will work, we can tell fairly easily what won't work.  If it doesn't
> address anything that phishers are doing then we know, without even bothering
> to deploy it, that it'll have no effect.


I feel like we're not really arguing here.  Nevertheless it is
Saturday, and I'm bored, so here goes.

1. Phishing isn't the only problem right?
2. To some degree this is a game where we have to guess their next
step, and make that harder too.
3. Who are the people arguing that TLS/HTTPS is a defense against
phishing that is doing any "real" work on any of this other than
pitching products/junk?

Getting to credentials that can't be easily given away to the wrong
party would certainly be a step in the right direction.  Several
things are hopefully working in that direction.  I'd love to have some
stats on whether people who use things like 1password/lastpass
actually get compromised less since those tools save your password,
and know whether you're on the "right site."

Please don't forget that in the presence of malware on the client
machine most of this doesn't matter, and so depending on what you
think the balance is between phishing and malware for stealing
credentials and/or monetizing accounts, you have a different set of
things to do to make progress.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Diginotar Lessons Learned (long)

[Andy Steingruebl]

On Sat, Sep 10, 2011 at 10:38 AM, Peter Gutmann
 wrote:

> My concern with this is that we've spent the last fifteen years energetically
> fixing the things that aren't being exploited.  When do we start fixing the
> things that are?

Got a prioritized list?  I'll tell you what I'm doing about them.
Quite seriously actually...


> people proposing new Rube Goldberg schemes - me included - should feel
> confident enough in them that they're prepared to say "My scheme, if adopted,
> will lead to an X% decrease in phishing".  It doesn't even have to be 25%,
> let's make it really easy and say 5%, or even just "statistically
> significant".  If you can't do that then you're not really proposing a
> solution but just looking for guinea pigs).

Actually, figuring out whether your solution will actually work is an
experiment right?  We can't know in advance for all of them, and w
can't even always A/B test things.  How much does DKIM signing help
against phishing?  How much does getting certain email providers to
reject things unsigned for a given domain?  How about formatting all
of your mails a certain way, only including links to your own domain,
etc.  Do you want to do each of those serially, with A/B testing?
You'll be waiting for years before you get the results.  Or you can
try all of them, over some period of time, hoping they make a
difference, and if the total phishing numbers are down, you win, as
long as you spent less to implement than you save in costs either in
direct losses or other metrics you care about like consumer
trust/spending/etc.

Me, I'm trying to stay ahead of the curve if I can.  Attackers aren't
spending a lot of time compromising home networking devices like
routers/modems, but we know some are vulnerable.  I'd just as soon
start fixing those things now, *before* people start abusing them.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] wont CA hackers CA pin also? and other musings (Re: PKI "fixes" that don't fix PKI (part III))

[Andy Steingruebl]

On Sat, Sep 10, 2011 at 11:46 AM, Ian G  wrote:
>
>>  2) Phishing using a similar-looking domain name.
>
> Yes. That's the big one in this space. Afaik.

I'd be surprised actually.  Most phishing sites are mass-compromises
of other websites, or mass-hosting on funky names/addresses, often
nothing like the site being phished. Look-alike isn't the dominant
trend these days, though I'll try to pull some phishtank stats to show
it.


- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Diginotar Lessons Learned (long)

[Andy Steingruebl]

On Sat, Sep 10, 2011 at 9:43 AM, James A. Donald  wrote:
>
> Most attacks aim to obtain shared secrets, so, obviously, a major solution
> is not fixing PKI, but SRP

Though aren't the most recent issues related to obtaining things other
than shared secrets?  The attacks against CAs recently haven't been to
perform financial attacks, they have been to get identity information,
which SRP isn't going to protect right?

I don't disagree that *most* attacks are about finances, but quite a
number are also about stealing other confidential information.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Diginotar Lessons Learned (long)

[Andy Steingruebl]

On Fri, Sep 9, 2011 at 6:22 PM, Peter Gutmann  wrote:

> May I make the following modest proposal:
>
>  A "fix" (of whatever form you want to try) is only regarded as valid if it
>  leads to at least a 25% decrease in phishing, measured over the interval
>  before and after its introduction.

We've had this discussion before.  Attackers will go wherever the
attacks are easiest, and if we don't fix things we know are attackable
(all/most of them) we're just pushing the problem around, not really
making the bad guys jobs easier.

We still need to prioritize of course, and fix the things being
exploited rather than just increasing key-lengths (the typical
approach) but that doesn't mean that fixing things that aren't being
exploited now, but we know can be exploited, is a waste of time.

Right?

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Symantec gets it wrong

[Andy Steingruebl]

On Thu, Sep 8, 2011 at 1:30 AM, Ralph Holz  wrote:
> Hi,
>
> I (still) cannot believe how Symantec reacts to the DigiNotar breaches -
> basically ignoring the known shortcomings:
>
> http://www.symantec.com/connect/blogs/why-your-certificate-authority-matters

To be contrarian for a moment

In the "old days" ( a few months ago) the only really difference for a
customer between most CAs was how widely their trust was distributed.
What platforms (Windows, which mobile phones, etc).  Their customers
didn't have to care about quality, and really didn't have to care
about the CA going away, except if the CA went bankrupt or
something...

Today, maybe that has changed ever so slightly?  If a customer now
fears that their/A CA will actually get de-listed from the popular
platforms, thus causing them an outage, maybe customers start
demanding CAs that are less likely to get de-listed? Maybe ones that
can demonstrate better security controls, or somesuch?

This isn't to say it justifies or supports the marketing campaign, but
perhaps there is a real message hidden in there after all?

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] preventing protocol failings

[Andy Steingruebl]

On Wed, Jul 13, 2011 at 8:40 PM, Peter Gutmann
 wrote:

> Maybe we travel in different circles, but both in sysadmin circles and in
> instances where it's come up in the past on security lists as an example of a
> successful security protocol, it reason for success has always been presented
> as a telnet replacement (and other usage followed from that).

Right, I agree it was a telnet replacement, but my argument is that
the value proposition wasn't just or event mostly security.  It plain
old just worked better, the security benefits were just a nice
addition.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] preventing protocol failings

[Andy Steingruebl]

On Wed, Jul 13, 2011 at 7:11 AM, Peter Gutmann
 wrote:
> Andy Steingruebl  writes:
>
>>The way it for for everyone I knew that went through it was:
>>
>>1. Sniffing was sort of a problem, but most people didn't care
>>2. Telnet was quite a bit of a pain, especially when using NAT, and wanting
>>to do X11 forwarding
>>3. Typing in your password again and again over telnet (which did have
>>advantages over rlogin/rsh) was a pain.
>>
>>Enter SSH.  It solved #1, but the big boon to sysadmins to figure it out and
>>installed it was that it *really* solved #2 and #3, hence major adoption.
>
> Uhh, this seems like a somewhat unusual reinterpretation of history.  SSH was
> primarily an encrypted telnet, and everything else was an optional add-on
> (when it was first published it was almost rejected with the comment "this is
> just another encrypted telnet").  The big boon to sysadmins was that (a) you
> could now safely type in your root password without having to walk to the room
> the box was in to sit at the console and (b) you could build and run it on
> pretty much everything without any hassle or cost.  That combination was what
> made it universal.

Hmm, do you know that many sysadmins outside high-security conscious
areas that really cared about typing the root password over telnet,
especially back in 1997?  I don't.  Academia and banks cared, and
often deployed things like securid or OPIE/SKEY to get away from this
problem, but your average IT shop didn't care at all.

Or are you really suggesting we got massive SSH adoption because of
the security properties?   Certainly not in my experience...

Maybe this calls for a survey/retrospective on reasons for adoption of SSH? :)

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] preventing protocol failings

[Andy Steingruebl]

On Tue, Jul 12, 2011 at 3:56 PM, Ian G  wrote:

> The SSH-vs-telnet example was back in the mid-90s where there were two
> alternatives:  secure telnet and this new-fangled thing called SSH.

The way it for for everyone I knew that went through it was:

1. Sniffing was sort of a problem, but most people didn't care
2. Telnet was quite a bit of a pain, especially when using NAT, and
wanting to do X11 forwarding
3. Typing in your password again and again over telnet (which did have
advantages over rlogin/rsh) was a pain.

Enter SSH.  It solved #1, but the big boon to sysadmins to figure it
out and installed it was that it *really* solved #2 and #3, hence
major adoption.  I know this wasn't the case for everyone to adopt it,
some people did it purely for security reasons.  That said, the major
threat was the passive attacker, the person running a sniffer on some
network.  Against them SSH was incredibly effective.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] preventing protocol failings

[Andy Steingruebl]

On Tue, Jul 12, 2011 at 2:24 PM, Zooko O'Whielacronx  wrote:
>
> When systems come with good usability properties in the key management
> (SSH, and I modestly suggest ZRTP and Tahoe-LAFS) then we don't see
> this pattern. People are willing to use secure tools that have a good
> usable interface. Compare HTTPS-vs-HTTP to SSH-vs-telnet (this
> observation is also due to Ian Grigg).

I reject the SSH key management example though.  Especially if you've
ever maintained a large number/variety of unix servers running SSH,
where hardware failures, machine upgrades, etc. lead to frequent SSH
key churn.  In those cases the only solutions are:

1. Automate key distribution to things like the /etc/known_hosts file
via means that aren't built into or supported by SSH itself really,
they are an adhoc add-on.
2. Go to insane pains to ensure that keys don't ever change. Quite
tricky when you're trying to automate OS installs, etc.
3. Use keys-in-DNS for this, which defaults back to something quite
easy to attack.
4. Give up. Accept all keys without fail and just assume you're not
getting owned.

In practice unskilled sysadmins in large environments go with #4 most
of the time, and you're right back to where you started... you can't
defend against active attackers.

- Andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography