Re: SSL Root CA and Intermediate CA Certs.
Edward Ned Harvey (openssl) openssl-Z8efaSeK1ezqlBn2x/y...@public.gmane.org writes: From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Michael Wojcik For someone who does want more background in cryptography, I'd recommend Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter is for people implementing cryptography, which beginners should never do. Huh - I thought Cryptography Engineering was the 3rd edition of Applied Cryptography, renamed. But now I look at it, it seems you're right, it's a different book entirely. Second edition of Practical Cryptography: https://www.schneier.com/book-practical.html However, I never got the impression that Cryptography Engineering was meant for people implementing new algorithms or anything like that. True, implementing isn't quite the right word. Using would be closer, I suspect, though that doesn't necessarily carry the notion of engineering (it's not a book about how to use PGP, or use some product that incorporates TLS). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL Root CA and Intermediate CA Certs.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Edward Ned Harvey (openssl) Sent: Wednesday, 23 April, 2014 21:05 Subject: RE: SSL Root CA and Intermediate CA Certs. I don't know how you learn about SSL/TLS, other than (a) reading the internet, Man, I *tried* to read the Internet, but to be honest I got bogged down somewhere around 2.0.0.0. (b) taking some courses on general cryptography (there is a free online course at coursera.com, which is quite good.) and (c) the thing that I actually found the most useful, a general book on cryptography called Cryptography Engineering I'd argue that knowing about cryptography, and especially about implementing cryptography, is not very helpful for understanding SSL/TLS. Once you understand the purpose of the primitives - symmetric and asymmetric encryption, message digests, and digital signatures - the details don't help you with the SSL/TLS protocols themselves, or even with choosing cipher suites. (While some suites are vulnerable to particular attacks, you can take the word of crypto experts on those points and weigh them against your threat model. Understanding the specifics of the threat isn't necessary.) And understanding the details of cryptographic implementation won't help at all with PKI. So I'd suggest starting with a quick cryptography primer that covers the primitives, and then something like Rescorla's /SSL and TLS/ book. It's not an exciting read, but then SSL/TLS is not an exciting subject. For someone who does want more background in cryptography, I'd recommend Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter is for people implementing cryptography, which beginners should never do. As a rule of thumb, don't attempt to implement cryptography until you know when it's appropriate to violate this rule. And as Schneier himself has pointed out numerous times, cryptography isn't the problem, or the solution, anyway. (If you think cryptography is the solution to your problem, you don't understand cryptography and you don't understand your problem.) How and why do you trust any root certs? Generally they're built-in to your OS or your browser, so you're just blindly trusting that those guys know what they're doing. And they don't, and they don't care that they don't. The SSL/TLS X.509-with-well-known-CAs PKI is fundamentally broken and frequently compromised. But there's little we can do about it, so we pretend it isn't. Of course the point of *any* security system is to raise the work factor for attackers until the cost of breaking the system is greater than the return for breaking it, under your threat model. SSL/TLS raises that cost over unencrypted communications. But it doesn't raise it nearly as much as it ought to, thanks to broken protocols, broken implementations, broken PKI, mismanagement, and user error. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
RE: SSL Root CA and Intermediate CA Certs.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Michael Wojcik For someone who does want more background in cryptography, I'd recommend Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter is for people implementing cryptography, which beginners should never do. Huh - I thought Cryptography Engineering was the 3rd edition of Applied Cryptography, renamed. But now I look at it, it seems you're right, it's a different book entirely. However, I never got the impression that Cryptography Engineering was meant for people implementing new algorithms or anything like that. They very roundly and repeatedly beat into you, don't do that, without loads and loads of courses in mathematics, and a thoroughly vetted public and expert review process. (Such as AES/SHA, etc). They do a nice round job of covering the basics, describing what a block cipher is, what a hash algorithm is, PKI, symmetric/asymmetric, etc, what the characteristics are, how to think about threat models, and how to use these things in the ways that they're intended to be used, etc. So don't discount Cryptography Engineering, but definitely consider Applied Cryptography in addition, or instead.
Re: SSL Root CA and Intermediate CA Certs.
On Thu, Apr 24, 2014 at 12:57:36PM +, Michael Wojcik wrote: [snip] How and why do you trust any root certs? Generally they're built-in to your OS or your browser, so you're just blindly trusting that those guys know what they're doing. And they don't, and they don't care that they don't. The SSL/TLS X.509-with-well-known-CAs PKI is fundamentally broken and frequently compromised. But there's little we can do about it, so we pretend it isn't. Well, there certainly is something we can do about it, but you won't like it any more than I do: 1. Empty all of your trust stores. 2. Add the cert.s of all CAs you already trust (if any) to your trust stores. 3. Investigate each CA you don't yet trust. As you come to trust one, add it to your trust stores. 4. Pay attention to the CAs you trust, and evict any that seem to have declined to a degree that worries you. 5. Goto 3. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: SSL Root CA and Intermediate CA Certs.
On 23 Apr 2014, at 2:23 PM, Kaushal Shriyan kaushalshri...@gmail.com wrote: I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology. The closest thing you'll probably encounter in the real world to a digital certificate is a diploma or degree from an educational institution. Anyone can write John Smith (PhD) on a piece of paper, that doesn't indicate anything special or prove anything. We might improve that by writing John Smith (PhD), Faculty of Philosophy on that piece of paper, but again, which faculty of philosophy? Never heard of them. Still, the piece of paper is useless. We can however write John Smith (PhD), Faculty of Philosophy, University of Cambridge on the piece of paper and sign the paper by putting a great big seal on the paper to make the paper hard to forge. In theory, we have heard of and trust the University of Cambridge, and in turn the University of Cambridge trusts the Faculty of Philosophy, which in turn trusts John Smith. If we trust the University of Cambridge, then we trust John Smith. If we were using digital certificates instead of a certificate you might hang on a wall we might create a certificate called cn=John Smith (PhD) and get John Smith to sign it. This cert is largely meaningless, given that in order to trust John Smith we need to already trust John Smith using some out-of-band method. This is a self signed certificate. If we were using certificates with a full certificate authority, we would instead have a certificate called cn=John Smith (PhD) issued by and signed by ou=Faculty of Philosophy which is in turn issued by and signed by o=University of Cambridge. The o=University of Cambridge certificate is called the ROOT CA certificate, because we have manually trusted that one using an out of band method (we might have got it built into our browser). The intermediate certificate is the ou=Faculty of Philosophy certificate, which is trusted by o=University of Cambridge and trusts cn=John Smith (PhD). John Smith is the leaf certificate trusted by the others. All you need to do is trust the root CA certificate o=University of Cambridge, and you automatically trust everyone they trust, including cn=John Smith (PhD). Instead of relying on a big elaborate piece of paper with a wax seal on it, you rely on a mathematical equation that verifies that the certificate is legitimate, but the idea is the same. Regards, Graham -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL Root CA and Intermediate CA Certs.
Hi, I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology. The closest thing you'll probably encounter in the real world to a digital certificate is a diploma or degree from an educational institution. and to take this anaology to the final step University of Cambridge is the Root - you know and trust. other Universities and Technical colleges are roots too - you know and trust them (your certificate store/keychain will be full of trusted Roots) - however, other orgs can hand out degrees too...these are affiliated to the main (root) CAs and have a lot of rules/checks/balances so, john smith, Degree from College of Town, underwritten by University of Foo you trust Fooso you then trust College of Town which means you trust the degree John holds. College of Town is, in this case, an intermediate Certificate. alan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL Root CA and Intermediate CA Certs.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Kaushal Shriyan
I am new to SSL/TLS Certificates. Please help me understand what is the
difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I
will appreciate if i can refer to some books or tutorials to know about
SSL/TLS
technology.
I don't know how you learn about SSL/TLS, other than (a) reading the internet,
and working on it a lot, (b) taking some courses on general cryptography (there
is a free online course at coursera.com, which is quite good.) and (c) the
thing that I actually found the most useful, a general book on cryptography
called Cryptography Engineering, by Bruce Schneier, Niels Ferguson, Tadayashi
Kohno.
The root cert is self signed (so it is signed by itself.) The intermediate
cert is signed by the root cert. And your leaf cert is signed by the
intermediate.
A client who receives the cert chain (the root, intermediate, and leaf) can
follow a process to (1) verify that the leaf cert is not corrupted, and that
the intermediate cert has verified it. (b) verify that the intermediate cert
is not corrupted, and that the root cert has verified it, and that the
intermediate cert is in fact authorized by the root cert to perform the
authorization of the leaf cert. and (c) verify that the root cert is among the
list of certs that the client trusts.
How and why do you trust any root certs? Generally they're built-in to your OS
or your browser, so you're just blindly trusting that those guys know what
they're doing.
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
