How to tell a fake SSL certificate from a real one

Anne & Lynn Wheeler wrote:

> This was part of end-to-end evaluation of using SSL for electronic
> commerce application. The problem was that as soon as the end-user
> starting clicking on buttons (that provided the URL) ... it
> invalidated the original requirements needed for meeting the

Nonsense. It' modified the "problem" slightly, and had no impact what
so ever on most of what we're discussing here.

The URL is still available for the user to inspect if they care to
glance at an address or status bar. So your theory fails on that fact
alone. However *most* users are still going to be providing their own
links when engaging in mission critical activities anyway, in the form
of previously stored (and working) bookmarks or such. Many will even be
typing in www.mybank.com (I do every time I visit my bank site). So
while your "theory" may hold true in select first encounter scenarios,
for the *vast* number of SSL connections it's completely irrelevant
even as a minor modification to the problem of user attentiveness.

> Endusers were encouraged to believe that SSL provided end-to-end
> security for electronic commerce. this helped convince merchants that
> they should pay for the digital certificates in support of SSL
> operation. click buttons broke critical part of the end-to-end
> paradigm that SSL (for electronic commerce) was dependent on.

I realize you're just cutting and pasting here, but do you have any
idea how tinfoil beanie this is beginning to sound? ;)

Nomen Nescio <nobody@dizum.com> writes:
> The URL is still available for the user to inspect if they care to
> glance at an address or status bar. So your theory fails on that fact
> alone. However *most* users are still going to be providing their own
> links when engaging in mission critical activities anyway, in the form
> of previously stored (and working) bookmarks or such. Many will even be
> typing in www.mybank.com (I do every time I visit my bank site). So
> while your "theory" may hold true in select first encounter scenarios,
> for the *vast* number of SSL connections it's completely irrelevant
> even as a minor modification to the problem of user attentiveness.

re:
http://www.garlic.com/~lynn/2007r.html#12 How to tell a fake SSL certificate from a real on
http://www.garlic.com/~lynn/2007r.html#17 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#18 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#19 How to tell a fake SSL certificate from a real one

the counter example is the subsequent vast proliferation of spamming
email with "click" URL and the problem with phishing websites ... as per
previous post.

the theory behind and design point of digital certificates and PKIs were
the letters of intent/introduction from sailing ship days for first time
interaction between strangers where the relying party had no other
recourse to the information about the party they were dealing with.

this recent post discusses some of the limitations on the actual value
of digital certificates and PKIs in SSL and other protocols for
electronic commerce
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game

where, in fact, the vast majority of electronic commerce transactions
involved repeated and/or well-known websites (i.e. transactions rates
quite skewed, negating the underlying justification for using PKI and
digital certificates in these applications).

original justification for using SSL for electronic commerce (by
far the most widely deployed use of SSL in the world) was

* is the website that the user think they are talking to, actually
the website they are talking to (SSL use for this was dependent
on user knowing the relationship between the website they believed
they were talking to and the corresponding URL)

* hiding information (typically transaction account numbers) for
information in transit

going to "known" websites with URLs from trusted repository easily
eliminates the justification and requirement for digital certificates
and PKI operation ... i.e. if there is a trusted respository of URLs
then it is possible to store the associated public keys in the same
repository. this is the certificateless mode of operation
http://www.garlic.com/~lynn/subpubkey.html#certless

recent discussion about (redundant and superfluous) certificate/PKI
operation being added to the simple public key specification of
for kerberos
http://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos
http://www.garlic.com/~lynn/2007q.html#5 Windows Live vs Kerberos

or old email from 1981 discussing pgp-like public key proposal
http://www.garlic.com/~lynn/2006w.html#email810515

even before we had finished the SSL related activity for
doing payment transactions on the internet ... something
that is frequently now referred to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#payment

.... we had started to realize that PKIs and digital certificates were
redundant and superfluous for most applications. As part of deploying
the backend portion (between webservers and something called a payment
gateway) we had specified requirement and implementation for (first) SSL
mutual authentcation. However, both the websites and payment gateway
was registered with the other, respective party ... making the
digital certificates redundant and superfluous (other than re-using
existing SSL library with requirement to have something called
a digital certificate).

Eliminating the requirement for digital certificates ... and the client
starting out with the servers public key (along with the servers URL),
it is possible to do a drastically simplified and lower overhead
SSL-like protocol.

The case for trusted respository of URLs ... along with the elimination
for any digital certificates ... can be extended to not only local
repositories ... but also online repositories like a secure, trusted DNS
.... where public keys are stored along with the mapping of domain name
to ip-address. Starting out the client-side of the protocol already
having the server-side public key ... can simplify the protocol
.... misc. past posts discussing how improving the security of DNS (with
registered public keys) is important to SSL domain name certification
authorities ... but also can represent a catch22 ... also eliminating
any requirement for PKI, certification authorities, and digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

in the mid-90s, after having worked on what is now comingly referred
to as electronic commerce (and associated SSL deployments), we
got involved with the x9a10 financial standard working group that
had been the requirement to preserve the integrity of the
financial infrastructure for all retail payments (internet,
non-internet, point-of-sale, debit, credit, stored-value/gift,
check/ach, card-present, card-not-present, etc ... i.e. ALL).
the result was x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959

part of the effort was doing some detailed threat and vulnerability
analysis ... for all kinds of retail transanctions (not just the
internet ones ... represented by electronic commerce, and the largest
deployed use for SSL). A big problem was the ease that account numbers
could be used for performing fraudulent transactions. Account numbers
showed in in a vast array of places ... things like internet
transmission (i.e. "data-in-flight") where SSL was being used to "hide"
the information ... but also things like transaction repositories
(i.e. "data-at-rest") which were required by a large number of backroom
processes (not normally apparent to customers and the general public).
This is somewhat the general "harvesting" vulnerability (skimming,
evesdropping, data breaches, security breaches, phishing, etc) ... lots
of past posts
http://www.garlic.com/~lynn/subintegrity.html#harvest

the vast number of places that account numbers existed and were required
led to the comment that even if the planet were buried of information
hiding encryption ... it still couldn't prevent leakage. so the x9.59
approach was to eliminate account number leakage as a vulnerability
(i.e. skimming, evesdropping, data breaches, security breaches,
phishing, etc, could still happen but the information wouldn't be useful
to the attackers).

the side-effect is not only doesn't it eliminate fraud from data
breaches and security breaches ... but also any evesdropping exploits on
the internet ... the type of thing that SSL is targeted at preventing
(and the major deployment purpose of SSL in the world today).

First off, there are numerous reasons that PKI and digital certificates
for SSL have become redundant and superfluous. Then it can be shown that
a single, common protocol (x9.59) ... can eliminate the major deployed
use of SSL for hiding accounts numbers at the same time eliminating much
of the fraud that arises from data and security breaches.

In message <d1f18fe915eaada7c8638c038cb8999f@remailer.paranoi ci.org>
Anonymous <nobody@remailer.paranoici.org> wrote:

>The SSL certificate used by your router *must* be registered to the
>router manufacturer, not some arbitrary IP address. This is a perfect
>case of a valid certificate generating the warnings it's suppose to
>generate because it's used in an implementation where it's impossible
>to do it any other way and still maintain a secure connection to your
>router. Linksys has no way of knowing that what your router's internal
>IP address will be.

Not at all. A self-signed certificate generated by the router with a
valid hostname would be best, since the user can simply install the
certificate once and never have warnings again.

Linksys simply cannot get a certificate registered for "192.168.0.1"
even if they wanted one.

Another option though, and this would be fairly trivial to implement if
Linksys (and others) were actually serious about security. Purchase a
certificate for "router.linksys.com", on the internet point that IP to
192.168.0.1 (or whatever is the standard for routers that use that
default) and then have the router's DNS server override that mapping and
supply the valid IP.

This would work for all browsers and all networks where the network uses
the router as a DHCP server, and the router passes DNS up to the ISP (as
is the case with most consumer grade routers)

As it is, they distribute a certificate which isn't valid, thereby
adding virtually no security, and worse, training users to ignore
certificate errors.

I consider that a negative in the grand scheme of things.

--
You can get more with a kind word and a 2x4 than just a kind word.

DevilsPGD wrote:

> In message <d1f18fe915eaada7c8638c038cb8999f@remailer.paranoi ci.org>
> Anonymous <nobody@remailer.paranoici.org> wrote:
>
> >The SSL certificate used by your router *must* be registered to the
> >router manufacturer, not some arbitrary IP address. This is a perfect
> >case of a valid certificate generating the warnings it's suppose to
> >generate because it's used in an implementation where it's impossible
> >to do it any other way and still maintain a secure connection to your
> >router. Linksys has no way of knowing that what your router's
> >internal IP address will be.
>
> Not at all. A self-signed certificate generated by the router with a
> valid hostname would be best, since the user can simply install the
> certificate once and never have warnings again.

That's the problem. Routers don't have valid host names from where
you need to access them from. Internally they're straight IP addresses.
Your suggestion would mean that every router would have to have a
public facing administrative interface (and no private administrative
interface).

Noooooooo thankyou. ;)

> Linksys simply cannot get a certificate registered for "192.168.0.1"
> even if they wanted one.
>
> Another option though, and this would be fairly trivial to implement
> if Linksys (and others) were actually serious about security.
> Purchase a certificate for "router.linksys.com", on the internet
> point that IP to 192.168.0.1 (or whatever is the standard for routers
> that use that default) and then have the router's DNS server override
> that mapping and supply the valid IP.

First of all, there is no standard. There's defaults, they vary from
router to router, and they can easily be changed (in many cases they
have to be).

Second of all this is flatly impossible. the 192.168.x.x IP block is
what's known as "non-routable". Those addresses can't be resolved from
the outside under any circumstances. If they could, every router still
set at defaults would conflict with every other similar router.

> This would work for all browsers and all networks where the network
> uses the router as a DHCP server, and the router passes DNS up to the
> ISP (as is the case with most consumer grade routers)
>
> As it is, they distribute a certificate which isn't valid, thereby

That's not true at all. The certificate is perfectly valid. And it's
trivial to decide whether or not to accept it in spite of the "doesn't
match" error *because* it's coming from a non-routable address. You're
manually entering the address, and that address can't exist anywhere
outside your local network (from your perspective). It's a sure bet the
certificate is kosher.

> adding virtually no security, and worse, training users to ignore
> certificate errors.

No security??

On the contrary, it's very hard security. Local networks are easier to
sniff than the Internet proper. For a home user with a single machine it
may not matter, but anything more complex than that and the SSL
encrypted connection is in some ways more critical than SSL connections
to outside servers. You're talking about the boundary equipment that
controls how traffic flows into, out of, and through the local net. Own
that, and you own every machine on that local net.

> I consider that a negative in the grand scheme of things.

I don't think you really understand what a router looks like on a
network. And you obviously don't understand non-routable IP
addresses. ;) There's no negative or positive about it really, it's
just the way things must be if you want a secure connection to your
router. It's silly to think that Linksys or anyone else should have to
have a different certificate for every piece of equipment they produce,
and it can't be done anyway because by default every model/series/class
of equipment is the same.

It simply just can't work that way.... :(

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Anonymous schrieb:

> Joan Battaglia wrote:

>> Is THIS a fake certificate?

It is not.

>> Here's what happened.
>> I went to http://torcheck.xenobite.eu/index.php

I'm the maintainer of that site.

> Yes. at this juncture you're dealing with a fake certificate. You have
> no way of immediately knowing whether or not someone has hijacked your
> connection to xenobite.eu, and is trying to "sniff" some bit of
> important information. You should immediately drop the connection and
> start asking questions. Which you just did. :-)

There is a way..

[...]

> protecting in the first place? This particular test is to show you what
> information your browser hands out over an HTTP connection as opposed to
> an HTTPS connection. That information can be different. especially if
> you're using something like Privoxy to scrub content. Privoxy can't see
> content inside an HTTPS connection so that scrubbing fails. A good
> reason to leave all that stuff in the hands of your browser itself, and
> plugins like NoScript. They can scrub content/headers before the data
> is encrypted.
> The Xenobite test is specifically designed to bring the above points to
> light, FWIW.

Yes, right!

[...]

> You might also use DNS to verify the IP address of Xenobite, however
> any IP could be in the certificate owner's field so this isn't reliable
> even if you're doing secure DNS lookups. This is where known trusted
> CA's come into play, and the certificate in question isn't signed by
> any.

Since the certificate is signed and contains a correct host in it's CN,
you're wrong in this case.

There is no need to provide a named host for proving connection trust,
because the more basic endpoint descriptor - the IP address - is a
somewhat more reliable factor for simple connection security, in my
opinion. It cannot be spoofed so easyly like DNS can be..

> Another way is to compare the fingerprint of the certificate with the
> fingerprint other people see. Using the SHA fingerprint because it's
> somewhat more secure...
>
> Yours:
>
> D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61 :11:B9:1B
>
> Mine:
>
> D3 CF DC 24 BC 3E E9 59 27 2B 82 51 27 67 D2 E8 61 11 B9 1B
>
> They match, so you know someone isn't attacking your connection
> specifically. I visited the site "naked", so you know it's not a Tor
> node, if anyone has managed to compromise the other end.

Exactly this you should do with the fingerprint information provided on
that page down below:

# Certificate's MD5 Fingerprint =
24:00:31:6D:F3:3B:E2:90:BC:73:CE:4D:BF:9C:2A:D7
# Certificate's SHA1 Fingerprint =
D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61 :11:B9:1B

Compare the numbers with your browser notification and on positive match
you're fine.

> A few more confirmations, especially from people who have examined the
> cert in the past, and you have a reasonable assurance that the
> certificate is acceptable. I wouldn't trust anonymous confirmations
> though, I could be anyone. ;-) But I do know in this case that if you
> pursue those lines you'll find people who will confirm the fingerprint.
>
> You can dig even deeper than that if you want to, but at this point I'd
> say we've determined that Xenobyte is simply using a free, untrusted

The certificate *is* trusted by StartCom: Your browser is *not*
complaining about the trust, only about the different hostname!

> certificate for the purposes of demonstrating how SSL affects your
> anonymous connection. The information you're giving Xenobite isn't
> critical, the trust factor is more than high enough to make you feel
> "comfortable" with what you're doing, so you can safely accept the
> certificate and proceed with the test.
>
> If the same scenario occurs with your banking site, however, you should
> run like hell. ;)

Of course!

- --

The origin problem I was trying to solve, was to provide my multi domain
single IP host with a secured connection layer without uncovering all
those domain names to the public by placing them all in the certificate.

Since it is not technically possible to install different SSL
certificates on the same IP on such multi domain hosts, I've decided to
put the IP instead of the host/domain into the CN to cover *all* domains
with an all-same factor (IP) somehow, for more easy verification by the
user. Just using a different domain name as CN would be more difficult
to check for plausibility, thought.

By using SSL for securing the connection against eavesdropping, instead
of using it for proving site identity, I wish the applications
(browsers) could do a second/alternate comparison using the IP for
making IPs as CN usable without hassle for the visitors...



Greets

- --

BlueStar88
__________________________________________________ ______
PGPID: 0x36150C86
PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKP+V/GOJMzYVDIYRA8UTAKCMR0Te6toep3+aZmJPB+IOR9BELACfUa9 O
4nF0m3DDmaKFTGf0UATF4Rg=
=EI24
-----END PGP SIGNATURE-----

BlueStar88 wrote:

> > protecting in the first place? This particular test is to show you
> > what information your browser hands out over an HTTP connection as
> > opposed to an HTTPS connection. That information can be different.
> > especially if you're using something like Privoxy to scrub content.
> > Privoxy can't see content inside an HTTPS connection so that
> > scrubbing fails. A good reason to leave all that stuff in the hands
> > of your browser itself, and plugins like NoScript. They can scrub
> > content/headers before the data is encrypted.
> > The Xenobite test is specifically designed to bring the above
> > points to light, FWIW.
>
> Yes, right!
>
> [...]
>
> > You might also use DNS to verify the IP address of Xenobite, however
> > any IP could be in the certificate owner's field so this isn't
> > reliable even if you're doing secure DNS lookups. This is where
> > known trusted CA's come into play, and the certificate in question
> > isn't signed by any.
>
> Since the certificate is signed and contains a correct host in it's
> CN, you're wrong in this case.

No, I'm stating a fact. The certificate is not signed by any Trusted CA
that's installed in any software I use. Your mileage may vary of course.

> There is no need to provide a named host for proving connection trust,
> because the more basic endpoint descriptor - the IP address - is a
> somewhat more reliable factor for simple connection security, in my
> opinion. It cannot be spoofed so easyly like DNS can be..

Indeed. But the problem is that there's no such thing as "IP Based"
certificates (outside closed systems). So unless you rewrite SSL you're
still going to get errors that have to be dealt with. One way to deal
with them is to use IP addresses rather than domain names, but this
only changes the nature of the error.

> The certificate *is* trusted by StartCom: Your browser is *not*
> complaining about the trust, only about the different hostname!

You're wrong. My browsers complain because StartCom isn't a trusted CA.
And yes I realize it ships with *some* browsers by default, but when a
trusted CA can't even produce a certificate that doesn't invoke errors
when visiting their own website, my policy is to remove it. So my
preferred Opera browser complains by default, and Firefox complains by
design.

Again, YMMV. ;)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Nomen Nescio schrieb:

> BlueStar88 wrote:

>> Since the certificate is signed and contains a correct host in it's
>> CN, you're wrong in this case.
>
> No, I'm stating a fact. The certificate is not signed by any Trusted CA
> that's installed in any software I use. Your mileage may vary of course.

Right, but that does not denial to be a signed certificate anyway. And
it is not 'just' a self signed certificate. The only problem is, that
your individual browser installation does not know the specific CA in
question.

You may want to update your certificate repo:

https://cert.startcom.org/?app=131

And/or check again using this URL:

https://217.160.111.190/

It is another problem, that only big (money making) CA's are making it
into the wide spread commercial browsers by default. But it is the users
choice to add any other CA or self signed cert he trusts.
The browsers automatic trust to some several CAs is not the complete
deal on using SSL. A self chosen trust to another CA or to a single self
signed cert is fulfilling the job sufficently for simple connection
security.
And you should individually extend your personal policy to this. There
are others you can trust too! ;-)

The SSL developers should extend it, to cover connection security by IP
address only, like an additional simple trust mode..



Greets

- --

BlueStar88
__________________________________________________ ______
PGPID: 0x36150C86
PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKnsK/GOJMzYVDIYRA3JOAKCQAr/lPzAfOAAIL86od2DEyxbuWwCgkZOF
Ytu7oVxKwe+NVQ9nx+04iHc=
=37PD
-----END PGP SIGNATURE-----

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> or old email from 1981 discussing pgp-like public key proposal
> http://www.garlic.com/~lynn/2006w.html#email810515

re:
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?
http://www.garlic.com/~lynn/2007q.html#73 Value of SSL client certificates?
http://www.garlic.com/~lynn/2007r.html#12 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#17 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#18 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#19 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#24 How to tell a fake SSL certificate from a real one


from my RFC index
http://www.garlic.com/~lynn/rfcietff.htm

recent PGP RFCs

http://www.garlic.com/~lynn/rfcidx16.htm#5081

5081 E
Using OpenPGP Keys for Transport Layer Security (TLS) Authentication,
Mavrogiannopoulos N., 2007/11/02 (8pp) (.txt=15300) (Refs 3280, 4346,
4366, 4880) (was draft-ietf-tls-openpgp-keys-11.txt)

http://www.garlic.com/~lynn/rfcidx16.htm#4880

4880 PS
OpenPGP Message Format, Callas J., Donnerhacke L., Finney H., Shaw D.,
Thayer R., 2007/11/02 (90pp) (.txt=203706) (Obsoletes 1991, 2440) (Refs
1423, 1950, 1951, 1991, 2045, 2440, 2822, 3156, 3447, 3629, 4086)
(Ref'ed By 5081) (was draft-ietf-openpgp-rfc2440bis-22.txt)

and as always ... clicking on the ".txt=nnn" field, retrieves the actual
RFC

could we be getting closer to certificateless SSL/TLS protocol?
misc. posts mentioning publickey certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#certless

for additional drift, posts mentioning possibility of general use of
"on-file" public keys (from the domain name system), including for a
SSL/TLS protocol like operation.
http://www.garlic.com/~lynn/subpubkey.html#catch22

and for even more drift ... a totally different DNS topic drift
(from a thread in comp.arch)
http://www.garlic.com/~lynn/2007r.html#48 Half a Century of Crappy Computing