How to tell a fake SSL certificate from a real one
What does a forged SSL situation look like to the user logging into email?
Do you have an example?
I read with interest all the help kindly provided by the likes of helpful
folks like VanguardLH & mark carter & others - which basically concluded
Tor compromised mail login passwords under both circumstances
- http (the Tor gets your mail password in the clear)
- https (the Tor _could_ impersonate the "certificate")
So, I ask ... how can I tell if a certificate is impersonated by a rogue
Tor? I routinely say yes to all certificate requests because I never
understood them. Now I will take the time to read them.
But, what does a fake SSL situation look like?
For example, I just initiated a connection to my legimate router: https://192.168.1.1
And it said (as it always does):
"Security Error: Domain Name Mismatch"
It went on:
"You have attempted to establish a connection with 192.168.1.1.
However, the security certificate presented belongs to Linksys.
It is possible, though unlikely, that someone may be trying to
intercept your communications with this web site.
It gave the recommendation:
"If you suspect the certificate shown does not belong to
192.168.1.1, please cancel the connection and notify the
site administrator?
Obviously this whole situation is a false alarm.
Does anyone have an example of a situation we can go to in order to see
what a "real" SSL forgery looks like to the user as they try to log into
their email web site?
Re: How to tell a fake SSL certificate from a real one
On 27 oct, 23:45, Joan Battaglia <joanmaxw...@sbcglobal.net> wrote:
You maybe should read about assymetrical encryption, it's all about
SSL, in wikipedia. Also, you can see it "live", by loging into an SSL
server like gmail by using OpenSSL (or even Lynx)
OpenSSL will allow you to log into gmail throught an SSL telnet
session. POP 3 protocol commands work as usual.
Asymetrical encryption : Gmail sends you a huge random number, from
which you PC compute de public key and return it to google (for
encryption) and the private key which you use to decrypt datas send by
gmail. The public key can be used for encryption. and the privat key
is not send; So it should be secure ;) almost
Re: How to tell a fake SSL certificate from a real one
In message <yjOUi.1213$yV6.108@newssvr25.news.prodigy.net> Joan
Battaglia <joanmaxwell@sbcglobal.net> wrote:
>So, I ask ... how can I tell if a certificate is impersonated by a rogue
>Tor? I routinely say yes to all certificate requests because I never
>understood them. Now I will take the time to read them.
Good plan. In general, any error at all in a SSL certificate and you
should be suspicious.
You can pull the fingerprint and compare it against the fingerprint of
that same SSL certificate provided via another method (like from a
different internet connection, and not passing through Tor), and then
once you've confirmed the error, safely proceed, but otherwise, by
ignoring SSL errors you are all but not using SSL at all.
(Well, in practice you're raising the bar to snoop on your traffic from
just sniffing to man-in-the-middle attacks. Tor is ideal for
man-in-the-middle attacks since you're intentionally passing your
traffic through several more hosts)
>But, what does a fake SSL situation look like?
>
>For example, I just initiated a connection to my legimate router:
> https://192.168.1.1
>And it said (as it always does):
> "Security Error: Domain Name Mismatch"
>It went on:
> "You have attempted to establish a connection with 192.168.1.1.
> However, the security certificate presented belongs to Linksys.
> It is possible, though unlikely, that someone may be trying to
> intercept your communications with this web site.
>It gave the recommendation:
> "If you suspect the certificate shown does not belong to
> 192.168.1.1, please cancel the connection and notify the
> site administrator?
The example above is a perfect case of a forgery -- Your router has an
invalid certificate, and the SSL layer is offering virtually no
protection against anything other then casual snooping.
A more common forgery case would be a valid URL, valid not-expired
timestamp, but a certificate which was not signed by a trusted authority
(And is otherwise 100% valid and complete)
--
You can get more with a kind word and a 2x4 than just a kind word.
Re: How to tell a fake SSL certificate from a real one
Joan Battaglia wrote:
> What does a forged SSL situation look like to the user logging into email?
> Do you have an example?
>
> I read with interest all the help kindly provided by the likes of helpful
> folks like VanguardLH & mark carter & others - which basically concluded
> Tor compromised mail login passwords under both circumstances
The problem is that their conclusions are not only unwarranted
technically, the results of the incident they're all talking about
whether they even realize it or not specifically state that all these
passwords were sniffed from connections that *were not* SSL/TLS
encrypted.
The only mystery here is why government agencies are not mandating
secure email access. It's astounding that any IT people in charge of
embassy communications could be so utterly clueless.
> - http (the Tor gets your mail password in the clear)
> - https (the Tor _could_ impersonate the "certificate")
Not unless your browser is horribly broken, or you blindly click the
'OK' buttons on dialogs without reading the clear and concise warnings
contained therein.
>
> So, I ask ... how can I tell if a certificate is impersonated by a rogue
> Tor? I routinely say yes to all certificate requests because I never
> understood them. Now I will take the time to read them.
You read the error message.
>
> But, what does a fake SSL situation look like?
A big pop up with a suitable warning symbol, and likely some sort of
"broken lock" notification in your status bar, all telling you that the
certificate doesn't match the site you're visiting, isn't signed, or
has changed.
> For example, I just initiated a connection to my legimate router:
> https://192.168.1.1
> And it said (as it always does):
> "Security Error: Domain Name Mismatch"
> It went on:
> "You have attempted to establish a connection with 192.168.1.1.
Exactly. The certificate was issued under the name of your router
manufacturer and you've entered a URL that doesn't match that name.
This is just one of the warning signs. Since you manually typed in a
non-routable IP address and know what it is you're trying to connect
to, you can ignore this particular warning. If you had been trying to
reach www.mybank.com ignoring it would just as obviously be a
BadThing(tm).
> Obviously this whole situation is a false alarm.
>
> Does anyone have an example of a situation we can go to in order to see
> what a "real" SSL forgery looks like to the user as they try to log into
> their email web site?
It will look exactly the same if this is how the forgers are trying to
attack you. Except the names will have changed of course... "You have
attempetd to establish a connection with www.mybank.com, how ever the
certificate belongs to XXXX". Or it will be unsigned, or won't match
the cert you've received on previous visits to your bank site. Or more
likely a combination of all three.
Re: How to tell a fake SSL certificate from a real one
bealoid wrote:
> Joan Battaglia <joanmaxwell@sbcglobal.net> wrote in
> news:yjOUi.1213$yV6.108@newssvr25.news.prodigy.net :
>
> [snip]
>
> > I routinely say yes to all certificate requests because I
> > never understood them.
>
> Unfortunatly you're not the only person to do so. :-( Other people will
> also click [YES] when some malwareis asking to be installed.
You're right of course. There's no shortage of inattentive or ignorant
users in the world. But this is a PEBKAC problem, not a software or
security methods issue.
>
> > Now I will take the time to read them.
>
> Good Luck.
It's really pretty simple. If you get an error that you didn't expect
or one that can't be easily explained by things like the Linksys
router issue or periodic rotation of expired SSL certificates, then you
don't accept them. Period. Unless you know for sure that the reason for
the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
or whatever negative response your software offers you. If you're in
doubt as to what to click, close the software all together.
If you've made a mistake and the connection was actually kosher then no
harm done. You have ample time to sort it out and make a final
determination about a given certificate. OTOH, if you err on the side
opposite of caution you may have precious few minutes to sort it out
before some script kiddie cleans out your bank account by wire
transferring your entire balance to Taiwan. :(
Re: How to tell a fake SSL certificate from a real one
On Sat, 27 Oct 2007 21:45:02 GMT, Joan Battaglia wrote:
> What does a forged SSL situation look like to the user logging into
email?
> Do you have an example?
>
> I read with interest all the help kindly provided by the likes of helpful
> folks like VanguardLH & mark carter & others - which basically concluded
> Tor compromised mail login passwords under both circumstances
> - http (the Tor gets your mail password in the clear)
> - https (the Tor _could_ impersonate the "certificate")
>
> So, I ask ... how can I tell if a certificate is impersonated by a rogue
> Tor? I routinely say yes to all certificate requests because I never
> understood them. Now I will take the time to read them.
>
> But, what does a fake SSL situation look like?
Mainly, you can see one because it obfucates the microcode in your HOSTS
files. Another way is to log to HTTPS the source code (unless it is C#) to
a NON HTTPS website.
> For example, I just initiated a connection to my legimate router:
> https://192.168.1.1
> And it said (as it always does):
> "Security Error: Domain Name Mismatch"
> It went on:
> "You have attempted to establish a connection with 192.168.1.1.
> However, the security certificate presented belongs to Linksys.
> It is possible, though unlikely, that someone may be trying to
> intercept your communications with this web site.
> It gave the recommendation:
> "If you suspect the certificate shown does not belong to
> 192.168.1.1, please cancel the connection and notify the
> site administrator?
>
> Obviously this whole situation is a false alarm.
>
> Does anyone have an example of a situation we can go to in order to see
> what a "real" SSL forgery looks like to the user as they try to log into
> their email web site?
Then when it loads, do a quick, CTRL-ALT-ampersand. If Java is scripted
server side only, then you can see the talisman algorithms. If not, then
you have to look at the compiled (previous not present, prior to browser
time-outs or MITM attacks).Either way, you have your answer.
Re: How to tell a fake SSL certificate from a real one
DevilsPGD wrote:
> In message <yjOUi.1213$yV6.108@newssvr25.news.prodigy.net> Joan
> Battaglia <joanmaxwell@sbcglobal.net> wrote:
>
> >So, I ask ... how can I tell if a certificate is impersonated by a rogue
> >Tor? I routinely say yes to all certificate requests because I never
> >understood them. Now I will take the time to read them.
>
> Good plan. In general, any error at all in a SSL certificate and you
> should be suspicious.
>
> You can pull the fingerprint and compare it against the fingerprint of
> that same SSL certificate provided via another method (like from a
> different internet connection, and not passing through Tor), and then
> once you've confirmed the error, safely proceed, but otherwise, by
> ignoring SSL errors you are all but not using SSL at all.
Agreed. The whole problem boils down to users not paying attention to
the warnings in front of their faces, or not using secure methods at
all.
> (Well, in practice you're raising the bar to snoop on your traffic from
> just sniffing to man-in-the-middle attacks. Tor is ideal for
MITM attacks have been occurring since long before Tor was ever in use.
Packages like dsniff have been around since the late 90's, including
specifc tools to spoof DNS, and then attack both SSH and SSL/HTTPS
connections. They're part of the reason SSH and SSL have evolved much
of their authenticity checking. My SSH client for example, absolutely
refuses to connect if keys change until the old key is manually removed
and the new one accepted.
Tor makes it a little easier for certain levels of technically inept
attackers to attempt certain attacks, but it in no way changes the
nature of the attack itself. The protocols and specifications will
protect you just the same over a Tor connection as they will a naked
connection.
> man-in-the-middle attacks since you're intentionally passing your
> traffic through several more hosts)
>
> >But, what does a fake SSL situation look like?
> >
> >For example, I just initiated a connection to my legimate router:
> > https://192.168.1.1
> >And it said (as it always does):
> > "Security Error: Domain Name Mismatch"
> >It went on:
> > "You have attempted to establish a connection with 192.168.1.1.
> > However, the security certificate presented belongs to Linksys.
> > It is possible, though unlikely, that someone may be trying to
> > intercept your communications with this web site.
> >It gave the recommendation:
> > "If you suspect the certificate shown does not belong to
> > 192.168.1.1, please cancel the connection and notify the
> > site administrator?
>
> The example above is a perfect case of a forgery -- Your router has an
> invalid certificate, and the SSL layer is offering virtually no
> protection against anything other then casual snooping.
???
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.
> A more common forgery case would be a valid URL, valid not-expired
> timestamp, but a certificate which was not signed by a trusted authority
> (And is otherwise 100% valid and complete)
Which also generates warnings and/or errors, and can't be installed or
even accepted by some software.
These types of forgeries are very uncommon though, because they require
that the attacker generate and selectively substitute unsigned
certificates for a whole range of potential targets. And do it in the
hopes that they're going to be the first one to submit the bogus
certificate to a potential victim, who in turn ignores the "unsigned"
warnings.
The chances of success are next to zero. It's a fruitless waste of
resources to generate certs with "Forged" UID's. Just as easy to
generate one, possibly even get it officially certified, and then
substitute that for the targets real certificate in hopes that a user
will miss the "changed" and/or "doesn't match" error.
SSL has been around for quite a while now. It's paid its dues. The
attacks we're talking about here are nowhere as easy to launch as some
people apparently think they are. Under normal circumstances (Tor usage
included) they're impossible to launch. It's only very rare cases of
user negligence or broken software where they'll have any chance at
success.
Re: How to tell a fake SSL certificate from a real one
Anonymous Sender <anonymous@remailer.metacolo.com> writes:
> You're right of course. There's no shortage of inattentive or ignorant
> users in the world. But this is a PEBKAC problem, not a software or
> security methods issue.
we were called in to consult with this small client/server startup
that wanted to do payments on their server. this resulted in something
that is frequently now called electronic commerce ... misc.
related postings http://www.garlic.com/~lynn/subnetwork.html#gateway
they also had invented this technology called SSL that they wanted to
use for the payments. As part of the payment transaction stuff ... we
had to do this detailed audit of the SSL protocol as well as walk thru
of this new organizations calling themselves certification authorities
.... and these things that they were issuing called digital certificates.
somewhat related past postings http://www.garlic.com/~lynn/subpubkey.html#sslcert
part of the browser/webserver interaction assumptions for SSL ... was
not only did the users understand the whole PKI gorp ... but were also
required to understand the relationship between the webserver they thot
they were talking to and the corresponding URL. SSL then would provide
for verifying the correspondance between the URL and the webserver they
were actually talking to (both are a requirement in order to result in
the webserver a user actually talks to, is the webserver that the user
thinks they are talking to).
this criteria was almost immediately compromised in actual deployments.
merchants fairly quickly found that use of SSL cut their thruput by
80-90 precent so they regressed to just using SSL for checkout/pay phase
with a CLICK button provided to enduser.
The CLICK button paradigm contributed sigificantly to obfuscating what
the user thot of as a website and the corresponding URL (they were no
longer paying attention to the actual URL used ... in part because they
were no longer actually typing it).
Now there was no longer (any SSL) verification of the initial website
contact ... and the (possibly fraudulent) website was then providing the
CLICK button URL for the SSL portion. An attacker could possibly obtain
a perfectly valid digital certificate that corresponds to the URL
provided by the CLICK button ... and effectively nearly all users would
never pay any attention.
This obfuscation has also been leveraged by various phishing email
exploits ... either by taking a user to fraudulent impersonation website
(with perfectly valid SSL digital certificate) and/or using some flavor
of proxy technology for a man-in-the-middle attack (again possibly with
perfectly valid SSL digital certificate) ... recent posts discussing a
man-in-the-middle using some form of proxy technology http://www.garlic.com/~lynn/2007q.html#6 what does xp do when system is copying http://www.garlic.com/~lynn/2007q.html#29 what does xp do when system is copying http://www.garlic.com/~lynn/2007q.html#31 what does xp do when system is copying
Re: How to tell a fake SSL certificate from a real one
On Sun, 28 Oct 2007 05:36:07 -0400, Nil wrote:
I followed everyone's advice and installed Tor/Vidalia/Privoxy.
I learned it's UP TO ME to determine if a certificate is fake.
So, I test the system - and I take your advice to READ the certificate
warning - but I still don't know what to do with the result.
Is THIS a fake certificate?
Here's what happened.
I went to http://torcheck.xenobite.eu/index.php
I clicked on the HTTPS-Mode button to see what it would say
Up popped a "Security Error: Domain Name Mismatch"
Which warned
You have attempted to establish a connection with
torcheck.xenobite.eu. However the security certificate
presented belongs to 217.160.111.190. It is possible, though
unlikely, that someone may be trying to intercept your
communication with this web site.
And, then:
If you suspect the certificate shown does not belong to
torcheck.xenobite.eu, please cancel the connection and notify
the site administrator.
So what do I do?
Most of these posts say to examine the certificate, so I press
the "View Certificate" button.
It says:
This certificate has been verified for the following uses:
SSL Server Certificate
Huh? Is that telling me something?
Then it says:
Issued To
Common Name (CN) 217.160.111.190
Organization (O) Kraus Computertechnik
Organizational Unit (OU) StartCom Free Certificate Member
Serial Number 01:84:54
To which my head is spinning - I guess I'm supposed to tell from this
if it's legitimate or not - but I don't know where to look.
It goes on:
Issued By
Common Name (CN) StartCom Class 1 Primary Intermediate Free CA
Organization (O) StartCom Ltd.
Organizational Unit (OU) Secure Certificate Signing
Huh? I still don't know what is wheat and what is chaff.
Moving on:
Validity
Issued On 9/25/2007
Expires On 9/24/2008
Does this tell me anything useful other than when it will expire.
I won't even go into what it says in the DETAILS tab!
Oh my. If all this which I'm supposed to read actually means something to
you guys, then you ARE rocket scientists!
What do I (decidedly not a rocket scientist) do with this information?
Is this a fake certificate or a real certificate?
How would I know?
Re: How to tell a fake SSL certificate from a real one
On Sun, 28 Oct 2007 14:43:58 GMT, Joan Battaglia wrote:
> Lastly:
> Fingerprints
> SHA1 Fingerprint
> D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61 :11:B9:1B
> MD5 Fingerprint:
> 24:00:31:6D:F3:3B:E2:90:BC:73:CE:4D:BF:9C:2A:D7
>
> I won't even go into what it says in the DETAILS tab!
> Oh my. If all this which I'm supposed to read actually means something to
> you guys, then you ARE rocket scientists!
>
> What do I (decidedly not a rocket scientist) do with this information?
> Is this a fake certificate or a real certificate?
> How would I know?
You will need to reboot, then check HOSTS for non 8080 correspondence.
Look for asterisks where there should be commas.
--
Vern, vermin, Kevin, whatever, I would have thought holding your hand as
we praised Ian would not have passed for a "I want to fuck you".
Re: How to tell a fake SSL certificate from a real one
On Sun, 28 Oct 2007 09:51:34 -0400, Anne & Lynn Wheeler wrote:
> we were called in to consult with this small client/server startup
> that wanted to do payments on their server. this resulted in something
> that is frequently now called electronic commerce ... misc.
> related postings
> http://www.garlic.com/~lynn/subnetwork.html#gateway
>
> they also had invented this technology called SSL that they wanted to
> use for the payments.
Small?
Netscapeware?
--
"I drink lots of water, know how to make bee's wax candles, play with
clay, eat mangoes nude, give great massages."
Re: How to tell a fake SSL certificate from a real one
On Sun, 28 Oct 2007 04:58:16 +0000 (UTC), Anonymous Sender wrote:
> You're right of course. There's no shortage of inattentive or ignorant
> users in the world. But this is a PEBKAC problem, not a software or
> security methods issue.
So basically you're telling us you don't have an argument anymore after
you found out Tor's developers have no problem with the commercial
nature of Xerobank so you're reduced to puerile whining. You conceded
your idiotic "stolen software" argument, abandoned the "bandwidth" issue
in record time, and rather than be adult enough to just admit your
mistakes you'd rather impress us with taking cheap shots at anonymous
posters in general from behind a remailer.
How pathetic. Thanks for clearing all that up for us this week too,
kiddo. :)
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust" http://www.acm.org/classics/sep95/
Re: How to tell a fake SSL certificate from a real one
On Sun, 28 Oct 2007 04:58:16 +0000 (UTC), Anonymous Sender wrote:
> bealoid wrote:
>
>> Joan Battaglia <joanmaxwell@sbcglobal.net> wrote in
>> news:yjOUi.1213$yV6.108@newssvr25.news.prodigy.net :
>>
>> [snip]
>>
>>> I routinely say yes to all certificate requests because I
>>> never understood them.
>>
>> Unfortunatly you're not the only person to do so. :-( Other people will
>> also click [YES] when some malwareis asking to be installed.
>
> You're right of course. There's no shortage of inattentive or ignorant
> users in the world. But this is a PEBKAC problem, not a software or
> security methods issue.
>
>>
>>> Now I will take the time to read them.
>>
>> Good Luck.
>
> It's really pretty simple. If you get an error that you didn't expect
> or one that can't be easily explained by things like the Linksys
> router issue or periodic rotation of expired SSL certificates, then you
> don't accept them. Period. Unless you know for sure that the reason for
> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
> or whatever negative response your software offers you. If you're in
> doubt as to what to click, close the software all together.
>
> If you've made a mistake and the connection was actually kosher then no
> harm done. You have ample time to sort it out and make a final
> determination about a given certificate. OTOH, if you err on the side
> opposite of caution you may have precious few minutes to sort it out
> before some script kiddie cleans out your bank account by wire
> transferring your entire balance to Taiwan. :(
> I have never insulted you to the best of my belief and knowledge.
ROTFLMAO!
That's the biggest load of shit you've EVER posted.
> It appears it is insulting to you when someone disagrees with you.
Talk about the pot calling the kettle black.
Insulting people who disagree with you is ALL you do.
> The remainder of the trolling rubbish removed.
Can't face the truth eh?
Just blame everyone else for doing what you do and run away little boy.
That makes it all go away.
NOT!
--
----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Re: How to tell a fake SSL certificate from a real one
Joan Battaglia wrote:
> On Sun, 28 Oct 2007 05:36:07 -0400, Nil wrote:
> I followed everyone's advice and installed Tor/Vidalia/Privoxy.
> I learned it's UP TO ME to determine if a certificate is fake.
> So, I test the system - and I take your advice to READ the certificate
> warning - but I still don't know what to do with the result.
>
> Is THIS a fake certificate?
>
> Here's what happened.
> I went to http://torcheck.xenobite.eu/index.php
> I clicked on the HTTPS-Mode button to see what it would say
> Up popped a "Security Error: Domain Name Mismatch"
> Which warned
> You have attempted to establish a connection with
> torcheck.xenobite.eu. However the security certificate
> presented belongs to 217.160.111.190. It is possible, though
> unlikely, that someone may be trying to intercept your
> communication with this web site.
> And, then:
> If you suspect the certificate shown does not belong to
> torcheck.xenobite.eu, please cancel the connection and notify
> the site administrator.
>
> So what do I do?
Well, it's written there. Do you suspect it? For me, torcheck.xenobite.eu
resolves to 217.160.111.190, and I got my reply through DNSsec.
> It says:
> This certificate has been verified for the following uses:
> SSL Server Certificate
> Huh? Is that telling me something?
Well, it should. The purpose of this certificate is to verify the identity
of the server. This is what you're using it for at the moment. Thus, this is OK.
If it told you that it's only purpose is for eMail verification, you should
suspect it when it's used for server identification.
> Issued To
> Common Name (CN) 217.160.111.190
> Organization (O) Kraus Computertechnik
> Organizational Unit (OU) StartCom Free Certificate Member
> Serial Number 01:84:54
> To which my head is spinning - I guess I'm supposed to tell from this
> if it's legitimate or not - but I don't know where to look.
CN, O and OU are well-defined in the X.509v3 standard. Why don't you look it
up? The CN seems a bit bogus to me.
> It goes on:
> Issued By
> Common Name (CN) StartCom Class 1 Primary Intermediate Free CA
> Organization (O) StartCom Ltd.
> Organizational Unit (OU) Secure Certificate Signing
> Huh? I still don't know what is wheat and what is chaff.
Well, then should definitely start reading. Class 1 typically is a
verification level by domain, thus they only send a reply to mail address at
the domain, and getting a reply then it the authentication. They
authenticate that the cert owner has control over the domain he's issuing a
certificate for, nothing more. They don't verify whether the Organization
belongs to this domain.
Class 3 is personal authentication by ID card and a written letter through
snail mail, Class 4 and above additionally verify that the Organization Unit
with the Organization exists.
Then again, you should always check the exact policy of the company issuing
the certificate. Why aren't you on the website of StartCom yet?
> Moving on:
> Validity
> Issued On 9/25/2007
> Expires On 9/24/2008
> Does this tell me anything useful other than when it will expire.
It tells you that this cert is current valid unless explicitly invalidated.
> Oh my. If all this which I'm supposed to read actually means something to
> you guys, then you ARE rocket scientists!
No, you're just (sorry for saying that) incompetent. Without even knowing
what the SSL certificate details means you should never ever do any
financial transactions on the web, and neither submit any personal data. In
fact you should better not even surf the web at all, because this is some of
the basic stuff that you absolutely need to know to not blind run into all
kind of troubles. The lack of seeing what's actually needed is the cause of
exactly the problems we're facing now, f.e. phishing, which, by definition,
actually is a pure non issue if everyone would just know this absolute minimum.
Re: How to tell a fake SSL certificate from a real one
Anonymous Sender wrote:
>> It's really pretty simple. If you get an error that you didn't expect
>> or one that can't be easily explained by things like the Linksys
>> router issue or periodic rotation of expired SSL certificates, then you
>> don't accept them. Period. Unless you know for sure that the reason for
>> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
>> or whatever negative response your software offers you. If you're in
>> doubt as to what to click, close the software all together.
>>
>> If you've made a mistake and the connection was actually kosher then no
>> harm done. You have ample time to sort it out and make a final
>> determination about a given certificate. OTOH, if you err on the side
>> opposite of caution you may have precious few minutes to sort it out
>> before some script kiddie cleans out your bank account by wire
>> transferring your entire balance to Taiwan. :(
>
>> I have never insulted you to the best of my belief and knowledge.
>
> ROTFLMAO!
>
> That's the biggest load of shit you've EVER posted.
WTF? This is actually the most sensible advice one could give. If in doubt,
an SSL error should be considered as a consequence of an attack, and the
protocols specifies to cancel the connection altogether.
Re: How to tell a fake SSL certificate from a real one
On Sun, 28 Oct 2007 15:49:20 -0500, Anonymous Sender wrote:
>>>> Now I will take the time to read them.
>>>
>>> Good Luck.
>>
>> It's really pretty simple. If you get an error that you didn't expect
>> or one that can't be easily explained by things like the Linksys
>> router issue or periodic rotation of expired SSL certificates, then you
>> don't accept them. Period. Unless you know for sure that the reason for
>> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
>> or whatever negative response your software offers you. If you're in
>> doubt as to what to click, close the software all together.
>>
>> If you've made a mistake and the connection was actually kosher then no
>> harm done. You have ample time to sort it out and make a final
>> determination about a given certificate. OTOH, if you err on the side
>> opposite of caution you may have precious few minutes to sort it out
>> before some script kiddie cleans out your bank account by wire
>> transferring your entire balance to Taiwan. :(
>
>> I have never insulted you to the best of my belief and knowledge.
>
> ROTFLMAO!
>
> That's the biggest load of shit you've EVER posted.
Except that I didn't post it, A$$hole. lol
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust" http://www.acm.org/classics/sep95/
Re: How to tell a fake SSL certificate from a real one
Ari wrote:
> On Sun, 28 Oct 2007 15:49:20 -0500, Anonymous Sender wrote:
>
> >>>> Now I will take the time to read them.
> >>>
> >>> Good Luck.
> >>
> >> It's really pretty simple. If you get an error that you didn't expect
> >> or one that can't be easily explained by things like the Linksys
> >> router issue or periodic rotation of expired SSL certificates, then you
> >> don't accept them. Period. Unless you know for sure that the reason for
> >> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
> >> or whatever negative response your software offers you. If you're in
> >> doubt as to what to click, close the software all together.
> >>
> >> If you've made a mistake and the connection was actually kosher then no
> >> harm done. You have ample time to sort it out and make a final
> >> determination about a given certificate. OTOH, if you err on the side
> >> opposite of caution you may have precious few minutes to sort it out
> >> before some script kiddie cleans out your bank account by wire
> >> transferring your entire balance to Taiwan. :(
> >
> >> I have never insulted you to the best of my belief and knowledge.
> >
> > ROTFLMAO!
> >
> > That's the biggest load of shit you've EVER posted.
>
> Except that I didn't post it, A$$hole. lol
Nobody said you did, "asshole".
So why would you "defend" yourself from something that you were never
even involved in? Freudian slip, or just some childish little game?
Re: How to tell a fake SSL certificate from a real one
Anne & Lynn Wheeler wrote:
<snip>
Congratulations Captain obvious!
You've just confirmed exactly what people have been saying all along.
The problem with SSL isn't SSL, but improper implementation and to a
greater degree user ignorance. Tor has nothing at all to do with
anything.
You did make one glaring mistake though...
> This obfuscation has also been leveraged by various phishing email
> exploits ... either by taking a user to fraudulent impersonation website
> (with perfectly valid SSL digital certificate) and/or using some flavor
> of proxy technology for a man-in-the-middle attack (again possibly with
> perfectly valid SSL digital certificate)
That's is a patently false statement. If a site spoofs certificates
they're not "perfectly" anything but forgeries. At which point the
problem lies squarely in the hands of the user. And education is the
only way to fix that broken wheel. The finest tools in the world placed
in the hands of the incompetent won't result in a fine family heirloom.
Again, this is in no way an SSL problem. The secure layer that can't be
misused is a myth.
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's a couple ways to resolve the issue in a more situation specific
way. The most obvious is determining exactly what it is you're trying
to do. IOW, is the information you're sharing with "Xenobite" worth
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.
So in essence you're really not transferring critical content. No
"bank account" information or anything. It's more of an informational
venture. That alone might be enough on which to base the decision to
accept the "fake" certificate and allow the connection.
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.
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...
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.
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
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. ;)
See what remailers do to you? Match that with this absurd, combative,
over-inflated valuation of yourself (" I have to be Anonymous, I am
sooooooo important") which flies directly in the face of "I will risk all I
am important about to play like a child on Usenet 7/24/366" combined w/ "I
have to uphold my Usenet reputation" shtick you are on. You can't keep up
with your own allegations.
You want to argue with me? When you can't keep up with your own postings?
Or be consistent between feeding your fucking ego and exposing yourself ("I
am Anonymous b/c I am laden with great tasks" v.s. "The Boss will kick my
ass to the curb")
You're a walking paradox of total bullshit. And a coward to boot.
Fuck off. If I want to banter with kids, techie wannabees, or dark corner
hiding flashers, I'll go to the nearest kindergarten, Star Trek
Extravaganza or urban alley where dogs piss.
> > > Except that I didn't post it, A$$hole. lol
>
> * Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*
>
> > Nobody said you did, "asshole".
>
> lol
>
> See what
<discard>
You forgot to explain why you would feel the need to defend yourself
against something that you had absolutely no part in what so ever. Your
name didn't even appear, yet you're denying doing it.
> *On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*
>
> >> I have never insulted you to the best of my belief and knowledge.
>
> On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:
>
> > > > ROTFLMAO!
> > > >
> > > > That's the biggest load of shit you've EVER posted.
>
> *ARI:*
>
> > > Except that I didn't post it, A$$hole. lol
>
> * Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*
>
> > Nobody said you did, "asshole".
>
> lol
>
> See what remailers do to you? Match that with this absurd, combative,
> over-inflated valuation of yourself (" I have to be Anonymous, I am
> sooooooo important") which flies directly in the face of "I will risk
> all I am important about to play like a child on Usenet 7/24/366"
> combined w/ "I have to uphold my Usenet reputation" shtick you are
> on. You can't keep up with your own allegations.
>
> You want to argue with me? When you can't keep up with your own
> postings? Or be consistent between feeding your fucking ego and
> exposing yourself ("I am Anonymous b/c I am laden with great tasks"
> v.s. "The Boss will kick my ass to the curb")
>
> You're a walking paradox of total bullshit. And a coward to boot.
>
> Fuck off. If I want to banter with kids, techie wannabees, or dark
> corner hiding flashers, I'll go to the nearest kindergarten, Star Trek
> Extravaganza or urban alley where dogs piss.
Poor precious Ari, skittering about from post to post desperately
trying to inject enough venom to make himself feel significant again
after his latest beating.
Old story, bright new day. Almost feel sorry for ya' kidlet.
Re: How to tell a fake SSL certificate from a real one
On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:
>>>>
>>>> If you've made a mistake and the connection was actually kosher then no
>>>> harm done. You have ample time to sort it out and make a final
>>>> determination about a given certificate. OTOH, if you err on the side
>>>> opposite of caution you may have precious few minutes to sort it out
>>>> before some script kiddie cleans out your bank account by wire
>>>> transferring your entire balance to Taiwan. :(
>>>
>>>> I have never insulted you to the best of my belief and knowledge.
>>>
>>> ROTFLMAO!
>>>
>>> That's the biggest load of shit you've EVER posted.
>>
>> Except that I didn't post it, A$$hole. lol
>
> Nobody said you did, "asshole".
>
> So why would you "defend" yourself from something that you were never
> even involved in? Freudian slip, or just some childish little game?
>
> Either way you're an obnoxious cretin.
I'll have to eat crow on that one, Ari, you didn't post that.
Re: How to tell a fake SSL certificate from a real one
Nomen Nescio <nobody@dizum.com> writes:
> That's is a patently false statement. If a site spoofs certificates
> they're not "perfectly" anything but forgeries. At which point the
> problem lies squarely in the hands of the user. And education is the
> only way to fix that broken wheel. The finest tools in the world placed
> in the hands of the incompetent won't result in a fine family heirloom.
>
> Again, this is in no way an SSL problem. The secure layer that can't be
> misused is a myth.
the comment wasn't about an attacker spoofing a certificate ... the
comment was about spoofing a website (at a totally different URL)
.... for which they might have a perfectly valid certificate.
the phishing attackers have been succesful with "click" paradigm
.... claiming to be one thing and actually having duplicated the site at
a totally different website/URL (for which they have a valid
certificate).
the issue was that the original SSL deployment about the end-users
knowing the binding between the site they thought they were talking to
and the URL for that site. Almost immediately there was widely
deployment based on using "click" buttons ... and for possibly for most
users they never acquired a knowledgeable awareness of the URL for the
website they believed they were talking to.
other phishing attacks have used variation on proxy technologies ...
having valid certificate for the URL (they had convinced victims) click
on. they would create a (SSL) session with the end-user ... and then
also create another (SSL) session with the "real" site ... and
transparently pass communication between the two sessions.
SSL was originally suppose to 1) guarentee that the website that the
user thot they were talking to was the actual website they were talking
to and 2) encrypt/hide that communication. However, there was somewhat
implicit assumption that the end-user had to explicity know/provide the
URL for the website they were talking to ... and the only SSL actually
did was guarentee that the website being talked to corresponded with the
provided URL. SSL was widely advertised as "1" ... which allowed
attackers to take advantage of the fact that majority of the users in
the world were interacting with websites ... not by explicity entering a
known URL ... but by clicking on buttons.
This divergent between what SSL was frequently being claimed to
solve and how it was actually being used started to happen very
early.
Part of this was almost immediately the majority of the merchant
ecommerce sites found that use of SSL cut their thruput by
80-90percent. As a result the switched to not using SSL for the initial
connection (which may have been actually entered by a user instead of
clikcing), but restricting its use for the pay/checkout portion of the
shopping experience ... which was a click operation ... for a URL
provided by (potentially fraudulent) merchant website.
Almost immediately, possibly 99.999 percent of the SSL use in the world
was open to attackers being about to redirect users to a different URL
(which users become conditioned to not pay attention to) and for which
the attackers could have a perfectly valid digital certificate.
there was a large disconnect between what most users in the world were
conditioned to believe was provided by SSL ... and what SSL was actually
providing.
How to tell a fake SSL certificate from a real one 