Home » Public » General » Verifying the Member Site certificate
 Verifying the Member Site certificate [message #5030] |
Thu, 01 July 2010 17:28  |
 Pete
Messages: 377
Registered: December 2009
Location: St. Louis, MO |
Senior Member |
|
|
Per Chris's request, here's some information on why you get a certificate
error when going to my.archreactor.org and how you can be sure your data is
safe. It also contains more than you ever wanted to know about digital
certificates. Well, maybe it would be more than you wanted to know if you
weren't a bunch of hackers. Since hackers, by definition, want to know
pretty much everything.
To start, I'm going to explain a bit (strike that, a lot) about how
certificates work. Which requires just a small bit of cryptography. I
promise I'll be gentle.
1. The Math (feel free to skip this):
If you took any algebra in high school (or even junior high), you might
remember factoring. That's where you take a number and you find all the
whole numbers that multiply together to get that number. For instance, if
you wanted a prime factorization of 34, you would divide it by a small,
known prime (2 is good), and see what you get (17). Then, you would try to
factor 17 (which is prime) and discover your two factors are 2 and 17.
For our purposes, it's not important you know how to factor numbers, it's
just important to realize that it's hard. In fact, it's hard for computers,
too. But, obviously, multiplication (the inverse of factorization) is easy
(17 * 2 = 34). Even computers know it's easy.
So, we can take for granted there are mathematical operations which are easy
in one direction, and extremely hard in the other direction (imagine the
numbers were 300 digits long and you'll get what I mean).
In fact, based on this bit of trivia, it's possible to construct a set of 3
numbers (E, D, and N) where the following is true:
- E cannot (easily) be computed from N and D
- D cannot (easily) be computed from N and E
- C = X^D mod N and X = C^E mod N -- for a given X, where X is between 0 and N.
Given that handy set of information. It means that given two of the three
numbers (say, E and N), we can "encrypt" any number X (where 0 < X < N) such
that it cannot be "decrypted" without either doing some major league
factoring or having D and N. It should be noted that the reverse is true, if
you encrypt something with D and N, only with E an N can you decrypt it. So,
there is no mathematical distinction between a public and private key (which
we'll learn about later).
This is the actual method used for RSA encryption (which is the most common
form of encryption used in digital certificate signing). Feel free to read a
bit more on the subject on Wikipedia: http://en.wikipedia.org/wiki/RSA
2. Public Key Cryptography
Okay, welcome back to those of you who skipped out on the math portion. No
worries, you didn't miss anything important. I know this new section also
has a scary title, too, but at least there are no four letter words in it
(like "math"). It's also not as scary as it seems. I'll try to make it fun.
In the last section, we learned that it's possible to create a set of
numbers (a public/private key pair) where it's easy to encrypt data with one
set of numbers, but extremely hard to decrypt that data with the same set of
numbers. You need a different set of numbers to decrypt the data easily.
That's the central tenant to public key cryptography.
Let's say that I have one part of a key pair (that's my "private" key) and I
give everyone I know (including you) the other part of the pair (the
"public" key). If you were to take some data and encrypt it with my public
key, then you can be almost certain that only I will be able to decrypt
it. Similarly, if I encrypt something with my private key, then only folks
with my public key can decrypt it!
But wait, you say, what's the point of encrypting something if everyone in
the world can decrypt it? Good question. The point is that if you use my
public key to decrypt something, and it comes out not looking like
gibberish, then you KNOW that my private key was used to encrypt it. Meaning
that you KNOW that only I could have encrypted that data!
And that little bit of trivia is very useful when dealing with.....
3. Digital Signing
Now, let's consider an interesting problem. Let's say I make a website. You
all trust me (riiiight?), so you're happy to store all your valuable
information on my website. But you want to be sure that you're on my
website, and not someone else's website that just looks like mine.
Based on the information from last section, it would seem that it's an easy
operation. When you get to my website, I take some standard message (such as
"my.archreactor.com is my website and it's currently 3:12PM on 7/1/2010")
and encrypt it with my private key. I then send that encrypted data to you
and you decrypt it with my public key. If it comes out as expected, you know
that I must have encrypted it, and that I must have done so at the specified
time. Of course, without a timestamp in there, some evil computer user might
send the same message to you later on from their fake site. But then it
wouldn't be the right time.
Likewise, you could also set up a simple system where you take some random
piece of data, encrypt it with my public key, then send it to my site. My
site should then be able to decrypt it and send it back to you. If the
messages match, you know my site has my private key, and must therefore be
owned by me!
However, there's a problem. What if you don't know my public key? Heck, what
if you don't know ME? Maybe you don't know me personally, but you know (and
trust) Deech, and Deech knows me and can vouch for me. Deech can then play
the role of a trusted authority (or, more commonly, a "certificate
authority"). Of course, then things get complicated. We have to create a
system for....
4. Digital Certificates
Okay, this one is a bit complicated, but bear with me. I'll do what I can to
make it easy-ish. Now might be a good time to take a break and let the last
three parts sink in. Because I'm going to assume that you've done that.
Starting....
... now. Okay, so, to recap, our problem is that you don't really know me.
You know and trust Deech, and Deech knows me, but you don't know me
specifically and you don't know my public key. So we have to come up with a
secure method to send you my public key and for Deech to vouch for my
identity. To do that, Deech needs to issue me a "digital certificate."
Since you know Deech, we can assume he can pass you his public key at any
time, securely. In the real world, browsers and/or operating systems will
include the public keys of popular certificate authorities. This is
generally considered a secure method of distribution. Now we just have to
figure out a way to use your knowledge of Deech's public key to verify my
identity.
Let's back up to when I create my website. I begin by going to Deech and
telling him I want him to vouch for me. He says, "Okay," and I give him my
public key. I also give him my website's address and a little info about
myself. He will then take that information (or, in the real world, a hash of
that information), encrypt it with his private key, and return the result to
me. In the real world, a certificate authority would charge a fee for this
service. I take the encrypted information Deech gives me and I put that
information (along with an unencrypted copy of the information) into a file.
That file is called a certificate.
When you come to my website, I will send you my certificate. You can then
take the encrypted part of the certificate and decrypt it with Deech's
public key. The only way that should work is if Deech had encrypted it with
his private key. So, if the information matches, you can be sure that Deech
created the certificate. Which means you can trust that any information in
the certificate was verified by Deech.
Since the certificate contains my public key, and the certificate is valid,
you now know my public key. You can also make sure that the address of the
site in the certificate matches my website's address (that prevents me from
selling off my certificate to some other website). And since you have my
public key, you can now encrypt data with it and send it to me and know that
only I can decrypt it. This can be used to encrypt a good old fashioned
shared secret and send it to me so that we can encrypt all of our
communications with each other. But that's a story for another thread.
5. But Pete, Why Do I Get an Error on my.archreactor.org???
Oh, yeah, I knew that I forgot something.
Here's the deal. as mentioned in #4, certificate authorities charge a fee in
order to generate a certificate. The most popular CA is VeriSign (you've
probably heard of them). They charge from $400/year up to $1,500/year for
certificates. So it's not exactly in our budget. Therefore, we are left with
the poor-man's option: Self-signed certificates.
A self-signed certificate is one where a website acts as its own certificate
authority. It signs its certificate with its own private key. The problem,
as you may have guessed, is that you have know way of validating the
certificate short of trusting the contents of the certificate. Obviously,
this isn't a very good idea. Because if someone wanted to impersonate
my.archreactor.org, they would just have to create their OWN self-signed
certificate.
So what's the point in doing the certificate at all? Well, that's a bit more
complicated. As I mentioned before, if you have my public key, we can use
that information to securely begin an encrypted session. Which is what
my.archreactor.org does. So even though the self-signed certificate doesn't
confirm the identity of the website. It does allow us to set up encrypted
sessions, meaning others can't snoop on your data while you're on the site.
Also, once you accept the certificate, it will stay on your computer, and if
anyone tries to substitute a new certificate in its place, your computer
will alert you to that. So if you have the right certificate now, you can be
confident that my.archreactor.org is who it says it is in the future.
But....
6. How do you confirm that your current certificate is valid?
Well, if you remember way back to #3 (I'll wait while you re-read it....
.... okay), the whole validation thing is actually pretty simple if you know
my public key already. So all we really have to do is find a secure way to
transmit that key to all the paranoid users who want to manually validate
the certificate. Of course, the forums are a reasonable choice. So here it
is:
EB 6A 68 C5 5B 77 8D EB 37 68 BF C3 D0 BD A0 BC CF CA 8B 51 20 F4 12 72 24
B3 0D A8 48 7E AD 32 45 64 4B D4 E4 A5 82 80 7F FF CF C0 2D 34 EB 6C E2 BB
02 DC 6E B3 13 CA 07 D0 E5 E6 08 54 41 EB 25 AA ED B2 96 7D EB 13 ED A1 B5
B3 D1 12 7E 0B 5B 3F 2F 54 2D 79 B2 2A 38 79 93 9F 60 9D 7A 06 AA 10 84 E9
24 74 0A FD A1 36 D0 0A CA C7 6A 14 F7 A1 AC 22 C5 F1 31 9F F7 09 7B F5 3D
30 FC D3
That's the actual public key for the my.archreactor.org SSL certificate. If
you want to manually verify, you will need to view the public key on the
certificate that you're sent when going to the site. How this is done varies
by browser. But for most browsers, there's some sort of lock or other icon
in the address bar that gives you access to the certificate. Open that up
and poke around for something that says "public key." It should match what's
above.
Note on Macs, once you accept the certificate, it will be in your keychain.
Just open your keychain access, go to "Certificates" and it will be listed
under my.archreactor.org.
Note that on Windows computers, the public key will be prepended with a
small header. I haven't been able to figure out exactly why this is, but it
seems that Windows just mis-parses RSA public keys. I've checked, the header
is on all keys, even those from trusted sources. So it's not a security
issue. The header is:
30 81 89 02 81 81 00
Following the header is where the public key (listed above) should begin.
Just verify that the public key in the certificate matches the public key
listed above and you can be sure that the certificate (or at least the
important part) is correct.
If you want another layer of security, you can check the thumbprint (aka
fingerprint) if your browser (or keychain) gives this option:
SHA1: 8A F3 95 A6 02 CE 74 C7 DE C2 90 D4 91 62 2E 11 5E 00 88 88
MD5: 76 7D C0 15 25 5D B2 56 6B 55 E0 89 BE 3A 3E 63
Now you can consider yourself over-informed on the subject of digital
certificates. Please feel free to email me or reply to this thread if you
have any questions/comments.
Thanks!
-Pete
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
[Updated on: Thu, 01 July 2010 21:05] by Moderator
|
|
| |
| Re: Verifying the Member Site certificate [message #5032 is a reply to message #5031 ] |
Thu, 01 July 2010 19:22  |
Pete
Messages: 377
Registered: December 2009
Location: St. Louis, MO |
Senior Member |
|
|
I knew the basics of the system from school. But I had to look up the
specifics on how the math on the RSA public key encryption worked (so
section 1 may not be 100% accurate). But I did learn the answer to a long
standing question I had. When I learned about how all this worked, I
wondered why they went to the trouble of hashing the contents of the
certificate before encrypting it. It would seem simpler just to encrypt the
whole thing. But it turns out that for RSA to encrypt something in one pass,
the encrypted material (represented as X above) needs to be quite small.
A hashing operation is pretty efficient (computationally), while encryption
is less so. So it's easier to hash and then encrypt then it would be to
encrypt the whole thing. And there doesn't appear to be any loss in the
security of the system. Also, by including the hashing step in the standard
procedure, it means you can easily sign content that's arbitrarily large. So
the same basic concept can be used to sign massive files and small
certificates alike.
I'm constantly amazed at how smart the people are who created this stuff.
They seem to think of everything.
Hope you appreciate your guest appearance, Deech. :-)
-Pete
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
|
|
|
| Re: Verifying the Member Site certificate [message #5037 is a reply to message #5032 ] |
Thu, 01 July 2010 22:24 |
MrHacks
Messages: 608
Registered: February 2010
Location: Florissant |
Senior Member |
|
|
You really do work for AT&T, Pete. You posted what should be a private key
in a public chat stream. (I'm Not trying to troll. It just makes more sense
to post these things in a secure area.)
On Jul 1, 2010 7:22 PM, "Pete L." <{email removed}> wrote:
I knew the basics of the system from school. But I had to look up the
specifics on how the math on the RSA public key encryption worked (so
section 1 may not be 100% accurate). But I did learn the answer to a long
standing question I had. When I learned about how all this worked, I
wondered why they went to the trouble of hashing the contents of the
certificate before encrypting it. It would seem simpler just to encrypt the
whole thing. But it turns out that for RSA to encrypt something in one pass,
the encrypted material (represented as X above) needs to be quite small.
A hashing operation is pretty efficient (computationally), while encryption
is less so. So it's easier to hash and then encrypt then it would be to
encrypt the whole thing. And there doesn't appear to be any loss in the
security of the system. Also, by including the hashing step in the standard
procedure, it means you can easily sign content that's arbitrarily large. So
the same basic concept can be used to sign massive files and small
certificates alike.
I'm constantly amazed at how smart the people are who created this stuff.
They seem to think of everything.
Hope you appreciate your guest appearance, Deech. :-)
-Pete
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show
up there, and vice versa. Consequently, when you quote people's entire
messages (like most email clients do automatically), it shows up in your
post on the forums. This is bad, because it clutters things up for forum
users.
Quote responsibly. Quote succinctly.
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
The ARCHives (Arch Reactor Library): Coming Soon!
|
|
|
| Re: Verifying the Member Site certificate [message #5038 is a reply to message #5037 ] |
Thu, 01 July 2010 22:26 |
MrHacks
Messages: 608
Registered: February 2010
Location: Florissant |
Senior Member |
|
|
Please show up tomorrow and explain all that to the Hackers.
On Jul 1, 2010 10:24 PM, "Bushido Hacks" <{email removed}> wrote:
You really do work for AT&T, Pete. You posted what should be a private key
in a public chat stream. (I'm Not trying to troll. It just makes more sense
to post these things in a secure area.)
>
> On Jul 1, 2010 7:22 PM, "Pete L." <{email removed}> wrote:
>
> I knew the basics of the syste...
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show
up there, and vice versa. Consequently, when you quote people's entire
messages (like most email clients do automatically), it shows up in your
post on the forums. This is bad, because it clutters things up for forum
users.
Quote responsibly. Quote succinctly.
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
The ARCHives (Arch Reactor Library): Coming Soon!
|
|
|
| Re: Verifying the Member Site certificate [message #5039 is a reply to message #5037 ] |
Thu, 01 July 2010 22:28 |
||cw
Messages: 769
Registered: August 2009 |
Senior Member
Administrator |
|
|
On Thu, Jul 1, 2010 at 10:24 PM, Bushido Hacks <{email removed}> wrote:
> You really do work for AT&T, Pete. You posted what should be a private key
> in a public chat stream. (I'm Not trying to troll. It just makes more sense
> to post these things in a secure area.)
uh, no, that's the public key that anyone can see just by visiting the
site and looking at the certificate details. Try it yourself.
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
|
|
| |
| Re: Verifying the Member Site certificate [message #5041 is a reply to message #5040 ] |
Thu, 01 July 2010 23:09 |
MrHacks
Messages: 608
Registered: February 2010
Location: Florissant |
Senior Member |
|
|
I know, that is why he should come tomorrow to the 2600 meeting.
On Jul 1, 2010 11:07 PM, "Keith Rogers" <{email removed}> wrote:
Pete - Thanks for that explanation!
Mr Hacks - You should read it sometime... it is very informative. -Keith
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show
up there, and vice versa. Consequently, when you quote people's entire
messages (like most email clients do automatically), it shows up in your
post on the forums. This is bad, because it clutters things up for forum
users.
Quote responsibly. Quote succinctly.
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
The ARCHives (Arch Reactor Library): Coming Soon!
|
|
|
| Re: Verifying the Member Site certificate [message #5045 is a reply to message #5041 ] |
Fri, 02 July 2010 10:43 |
Pete
Messages: 377
Registered: December 2009
Location: St. Louis, MO |
Senior Member |
|
|
Sadly, won't be able to make it to the 2600 meeting. But feel free to inform
people of the post. As noted before, if anyone has questions about anything
above (or if it's not clear -- which is totally understandable), please let
me know and I'll do what I can to improve/clarify it. This is a concept that
we see in action every day, but the vast majority of people don't understand
it. In fact, a recent study (link below) found that more than 96% of SSL
certificates are invalid. The overwhelming reason is because the domain name
doesn't match. As discussed above, if the SSL certificate doesn't match the
domain name, it should be considered invalid.
Chances are that this, in-and-of itself isn't a huge security threat, since
a fraudulent site wouldn't be able to initiate a secure session without the
appropriate private key. However, as I mentioned before, if the URL
validation doesn't work, someone could "sublet" their SSL certificate, and
it would lose the accountability generally associated with SSL certificates.
I didn't mention this in the initial post, but there is a process associated
with obtaining an SSL certificate where the issuer "gets to know you" a bit
(they confirm your contact information and whatnot). That way, it keeps
someone like me from running out and getting an SSL certificate marked "Bank
of America" or something like that. But if there's no domain check and Bank
of America gets their private key compromised, then someone could set up "
www.bankofamarica.com" with a "valid" SSL certificate marked "Bank of
America."
-Pete
Here's the study, as reported by eSecurityPlanet -
http://www.esecurityplanet.com/news/article.php/3890171/SSL-Certificates-In-Use-Today-Arent-All-Valid.htm
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
|
|
|
| Re: Verifying the Member Site certificate [message #5046 is a reply to message #5045 ] |
Fri, 02 July 2010 10:56 |
the_irrational_one
Messages: 228
Registered: August 2009 |
Senior Member |
|
|
> In fact, a recent study (link below) found that more than 96% of SSL certificates are invalid. The overwhelming reason is because the domain name doesn't match. As discussed above, if the SSL certificate doesn't match the domain name, it should be considered invalid.
For what it's worth, that "study" was deeply flawed, and has pretty much been debunked. Listen to this weeks episode of Security Now or check out the following link:
http://www.prlog.org/10773297-comodo-urges-clarification-in-the-preliminary-published-findings-from-qualys-ssl-certificate.html
I think this was just some company trying to generate some sales / press.
~Bob
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
|
|
|
| Re: Verifying the Member Site certificate [message #5048 is a reply to message #5046 ] |
Fri, 02 July 2010 11:34 |
Pete
Messages: 377
Registered: December 2009
Location: St. Louis, MO |
Senior Member |
|
|
Ahh, good to hear.
Though I have run across MANY partially-invalid SSL certs...
-Pete
_______________________________________________
ChitChat mailing list
{email removed}
http://lists.archreactor.org/listinfo/chitchat
Did you know: This list is synced to our forums. Messages posted here show up there, and vice versa. Consequently, when you quote people's entire messages (like most email clients do automatically), it shows up in your post on the forums. This is bad, because it clutters things up for forum users.
Quote responsibly. Quote succinctly.
|
|
|
Goto Forum:
Current Time: Thu Sep 9 09:56:58 CDT 2010
Total time taken to generate the page: 0.07387 seconds
|
Members
Search
Help
Register
Login
Home
E-mail to friend 
