SSL Certificates and HTTPS Protocol

[prateek chandan]

Can anyone provide me a basic idea of what are SSL Certificates and HTTS Protocol.. 
And Most Importantly if I need to run my my CSE Homepage with a HTTPS Protocol.. Is it Possible ?
And if possible what do I need to do ?

[Manish Goregaokar]

The HTTPS protocol basically uses RSA encryption to make messages untamperable (without detection), and unreadable to anyone but the sender/receiver.

RSA encryption needs a public and private key from each party (the names of the keys signify how sensitive they are, you can go about bandying your public key to everyone but you should never do that with your private key). The public and private keys are mathematically linked via an effectively one-way function (has to do with prime factorization). Alice, the sender, can use her private key, along with Bob's public key, to encrypt a message. This message cannot be read by anyone but Bob, who has the private key necessary to decrypt the message (since the message was encoded with his public key). In addition, Bob can verify that the message came from Alice by testing it against her public key.

Now, the goal here is to minimize man in the middle (MITM) attacks in HTTPS. If Alice and Bob have already securely exchanged public keys, then an attacker Eve cannot read or tamper with any of the messages. The most Eve can do is stop the messages from going through, which isn't too malicious since Bob would immediately find out.

The issue is, this requires at least one person to have securely sent their key over. One way to do this is to have a secure "key directory"[1] on the Web where all websites list their keys. This has the issue of being a single website, and requiring a ping/lookup every time you open an https website. You could distribute it, but it still needs a ping. Which is sub-optimal.

Thus we have the X.509 certificates, part of the SSL/TLS protocol. These use a method of trust chaining that effectively lets you be able to verify keys with ease.

What's done here is that each website on HTTPS has a certificate. The certificate lists the key and the domain name(s) that it is allowed to be used with. For example, this is what I see when I view GMail's cert with Chrome:

If you look at the details, you see

This latter bit is the "trust chain", established via signing of certs. See, RSA keys can be used for digital signatures as well[2]. A digital signature does not encrypt a message, but it prevents the message from being tampered with. If I sign a message with my private key and attach the signature to the original message, people will be able to verify that the signature was indeed mine, and if the message is tampered with the signature won't match anymore so they'll be able to detect it.

The trust chain is established like this: Each certificate has a field which contains a signature of the important parts of the certificate from its parent certificate ("CA certificate", CA stands for Certificate Authority), as well as a copy of the parent cert. This chain goes on till you reach a "root CA", which is a certificate that's built into the browser.[3]

Global root CAs are given permission to sign certificates at their discretion, of course maintaining some level of checking of domain name owners. Many also have the ability to create more CA certs (sometimes limited)[4].

So now, if I (the end user) want to use HTTPS with, say, mail.google.com, I will first ask them for their certificate. Then, I can locally verify the trust chain (because I don't need the internet to verify signatures), and generate my own keypair. I can encrypt this keypair and send it over. Now, both parties have each others' keys, and we can start full encrypted communication. All this without having to rely on any other website[5]

Of course, this shifts the trust from the network infrastructure[6] to the CAs[7] and the browsers which include root CAs. CAs are supposed to have a strict checking policy to ensure that the buyer of a certificate is indeed the owner of a domain.

To answer your CSE question, you can't. HTTPS is something that needs to be enabled Apache side, with Apache giving out the certificate. For testing purposes, you can create your own self-signed certificate and import it into your browser, and use the SSLCertificateFile and SSLCertificateKeyFile (and some others which I forgot) conf directives in Apache. Or do something with nginx. But this you can only do locally or on a server which you have root access to.

Also, even if you got root access to CSE's server, you would need to buy a legitimate certificate so that it would work. For that you need to establish domain ownership, which you won't be able to do unless you have root access to the minds of the CC junta as well. Or you could use the *.iitb.ac.in cert, but nobody's going to give you the private key for that one.

So nope, no HTTPS on CSE. You can pain your sysads to get a cert and enable it, though. (They can use the *.iitb.ac.in cert if CC lets them)

#MidSemLukkha

------ 

1: Kinda like MIT's PGP key server, except that's for PGP (which is more of a superset of algorithms in a standardized package) and this would be for RSA

 2: Signatures are another form of one-way algorithm, and like most, they rely on prime numbers. RSA keys (effectively a pair of primes) can be used here also.

 3. Which root certs get included into the browser is a rather confusing protocol and browser dependent.

 4. The ability for a certificate to create child certificates and child CA certs is governed by the "Certificate Basic Constraints" field. Check it out for the GMail cert chain (use the padlock icon at the top of your browser)

 5. There is something called an OCSP server which is used to quickly invalidate compromised certificates, and that may be contacted during the initiation of HTTPS. But that's not strictly necessary to the protocol.

 6. Totally untrustworthy, the TCP/IP protocol wasn't designed with the "security" of packets in mind. Plus, ISPs can monitor you (as can CC, in IITB) on HTTP.

 7. Also totally untrustworthy, unfortunately. Verisign's Site Finder is an example of this. But still, a known (fr)enemy is better than an unknown MITMer sitting on your network. They're liable, too, so less likely to pull tricks.

-Manish Goregaokar

--
--
The website for the club is http://wncc-iitb.org/
To post to this group, send email to wncc...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dilawar Singh]

[prateek chandan]

Thanks manish..
You wrote about HTTPS and SSL.. I studied and I understood the concept...
 Earlier when I wrote https://www.cse..../~id It gave apache error I studies and created a private and protected key pair using OpenSSL and then added it using httpd.conf so it gives a security issue but then opens the page
I  studied about it and and came to know that we need to get the CA certificate signed by some authority.The CA certificate I used was self signed so the browser wont accept it. You said it is not possible with cse server.. okay
 Say I have my own server and not the cse one and I want to host it using HTTPS protocol.. what to I need to do.. How will I get verified CA certificate signed by some authority ?​
PS : Is there a free way :P

[Pritam Baral]

The CA system is central to HTTPS. But it in no way dictates that you have to purchase a CA signed cert. If it is just for your personal use, you can always generate a CA cert yourself and use that to sign all your private sites(, basically: become your own CA.)

If it is for public consumption, then you need a "popular" CA. By popular, I mean popular with the browsers. When you pay a CA to sign a cert for you, you are paying for the browser base, not for the signing/crypto/cert.

There is one popular CA that provides signed certs for free. You just have to verify that you own the domain, and MX records (email) to the domain. But their UX sucks. Hint: go to Control Panel on the left.

[Pritam Baral]

Technical Mumbo-Jumbo Ahead (couldn't help it):

$ sed -i s/RSA/"Asymmetric-Key Cryptography"/g Manish_Goregaokar.answer

TLS (which is what the S in HTTPS stands for) is more complicated than that, but asymmetric crypto is at the heart of it all. TLS simply couldn't be achieved without asymmetric crypto, for now-obvious reasons.

BUT, asymmetric crypto isn't enough. Asking every client (read: browser, henceforth referred to as client) to maintain its own set of private-public keys for itself is not necessary. Asymmetric crypto isn't used for server -> client transmissions.

Instead, the server-client pair generate a temporary key (a single key) to encrypt all their messages with. Only the client and the server know this key, and nothing else on the path between them, even if they watched the entire communication till now, can know the key. The way it is achieved is:

*) Client decides an arbitrary (random) pre-master key. Only client knows this until now.
*) Client encrypts it with server's public key and sends it over.

      Anybody snooping can't decrypt the pre-master key without the server's private key

*) Server decrypts pre-mastr key. Now both client and server know pre-master key, and only those two do.

*) Both client and server operate on the pre-master key in a pre-defined manner, generating the same master key on both sides.

*) TLS is now ready. The stream can be encrypted-and-decrypted with this master key, which only client and server know.

This is a simplified view of what is sufficient for an effective TLS. In practice there is one more step. The master key is used to generate session keys (again, symmetric), and sessions keys are actually used to encrypt streams.

There is also another component to TLS: MAC. Message Authentication (Code) is used to required the integrity of the stream. Without it, a snooping agent could introduce garbage in the stream, even if they couldn't decode the stream itself.

Note: use of RSA is discouraged, since there are better alternatives available; better in the sense that more secure with less bits.

 

Regards,
Chhatoi Pritam Baral

[Dilawar Singh]

Technical Mumbo-Jumbo Ahead (couldn't help it)

https://www.youtube.com/watch?v=zWRykybDpYA

Couldn't help it!

- Dilawar