Understanding how HTTPS works

PHP
1

Hi all! :wavey:

Okay, here is my first technical question as a new member of the PHP forum! (Be gentle!) :stuck_out_tongue:

Would someone please help me to understand what is required to establish a “secure connection” between an end-user’s computer and my website on a server??

I’m not as interested in PHP code, per se, although you can certainly include some here. The goal of this question is to understand what all I am going to need to develop (or buy)!

Scenario:

Jane Citizen goes to my Seminar Registration website and is required to Log-In to do something.

What do my Web-Host, Web-Hosting Account, and my PHP code need to do to create an “encrypted tunnel” so that all of Jane’s info is safe (e.g. password)?

I know that I need to buy an SSL certificate with my web-host.

And there is code that somehow switches the page/connection from HTTP://SomePage.php to HTTPS://SomeProtectedPage.php, but what exactly is the process to do that??

Hope that makes sense and was not too long-winded?! :smiley:

Thanks,

Amy

2

The security certificate contains keys for asymetrical encryption/decryption.

When you access a page via https it downloads the encryption key part of the security key with the certificate and the browser uses that to encrypt everything being passed back to the server. That content is unable to be converted back into readable text without the decryption key which remains in the security certificate stored on the server so that the server hosting the site is the only place where that content can be decrypted.

There is no PHp or any other client or server side languages involved in this process as it is all handled by the browser, the web server, and the security certificate.

3

So the SSL Certificate would be sending its “public key” to whatever client is accessing an HTTPS page?

That content is unable to be converted back into readable text without the decryption key which remains in the security certificate stored on the server

Now you are referring to the SSL Certificate’s “private key”?

so that the server hosting the site is the only place where that content can be decrypted.

And presumably the SSL Certificate and pits “private key(s)” are relatively safe from being compromised?

There is no PHp or any other client or server side languages involved in this process as it is all handled by the browser, the web server, and the security certificate.

Okay, but lets say there is some portion of my website that require information to be protected. Specifically, let’s say I need to build a Log-In Module.

Jane User is on a page using HTTP, but needs to update her user preferences. So she clicks on a button “Update User Preferences” and is taken to a Log-In page which should now have an HTTPS. As she attempts to log in, her Username and Password are sent to the server in an encrypted form.

Can you be a little more specific in code-neutral terms with what my code (i.e. PHP or any server-side code) has to do to make what you discribed above happen?

Also, to clarify, when you use SSL/HTTPS, are you sending your data through an “encryoted tunnel” or is the data just being encrypted on the client side and then sent over an unsecured connection (i.e. plain-text) but since it is encrypted it is safe? :confused:

Thanks,

Amy

P.S. Wow!! I just figured out that you guys (and gals) in eastern Australia are 17 hours ahead of me?! :eek:

4

The certificate (and HTPPS) “protects” the content as it is sent from the browser to the server. It is encrypted using the certificate public key by the browser and decrypted by the private key once it reaches the server.

It passes down the same communication channel to get from one computer to the other as all communication passes. That is sometimes considered to be an “encrypted tunnel” since to anything other than the server it is intended for the content is unreadable.

Unless you have an actual physical leased line connection from your computer to the server that doesn’t pass through the internet you are relying on the encryption to create a virtual tunnel.

Apart from using HTTPS and a certificate to encrypt what is typed in as it passes from the browser to the server, the rest of what you need both in the web page and on the server is exactly the same as you would need to perform the processing if you were using HTTP and passing the login info to the server as plain text. The same form on the web page collects the info and the same PHP (or whatever) script on the server processes the info on the server as you would have used before deciding to switch to using HTTPS instead of HTTP.

5

Okay, so I got that right.

It passes down the same communication channel to get from one computer to the other as all communication passes. That is sometimes considered to be an “encrypted tunnel” since to anything other than the server it is intended for the content is unreadable.

Unless you have an actual physical leased line connection from your computer to the server that doesn’t pass through the internet you are relying on the encryption to create a virtual tunnel.

Okay, so when people say HTTPS is an “encrypted tunnel” that is really a misnomer?!

So it is NOT like a VPN where I think (??) you actually do have an “encrypted tunnel/connection”, right?

Apart from using HTTPS and a certificate to encrypt what is typed in as it passes from the browser to the server, the rest of what you need both in the web page and on the server is exactly the same as you would need to perform the processing if you were using HTTP and passing the login info to the server as plain text. The same form on the web page collects the info and the same PHP (or whatever) script on the server processes the info on the server as you would have used before deciding to switch to using HTTPS instead of HTTP.

Okay, so it is just a matter of telling PHP to send the data via HTTPS vs HTTP?

Would it go like this…

[COLOR=“Blue”]***************
Form: “Hey PHP, this is sensitive data, let’s send it via HTTPS…”

PHP: “Okay, we will use a different, secure connection.” (I think Port 443??)

Server: “Oh, I’m getting a request to send me data over the HTTPS connection, I better send my public key!”

Browser: “Thanks for your public key!”

Browser: “I’ll encrypt the sensitive data now!”

PHP/Browser: “Here comes some encrypted data, Mr. Server.”

Server: “Oay, let me now use my private key to decryot the senstive data that the browser encrypted with my public key.”
***************[/COLOR]

Hope you like my mini screenplay? :lol:

Thanks,

Amy

6

Here is a scheme of how SSL connection works:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzas.doc/sy10660_.htm
Actually you can make and people do make VPN tunnels using SSL. For instance with stunnel.

7

A VPN tunnel is also just encrypted data being sent across the internet. ANY “tunnel” on the internet just means it is encrypted at one end and decrypted at the other so as to be not readable to anyone apart from those who are entitled to read it.

PHP has no involvement in the HTTPS part of the process. It only gets the data after it has been decrypted on the server.

8

Some remarks about screenplay :wink:
PHP is a servant for Server, he does not meet in person with Browser. Browser only talks to Server.
Browser and Server only use Public/Private keys to encrypt SessionKey that is then used to (symmetrically) encrypt all their talk (Because talking asymmetrically would take too much time - they are not that fluent in this :wink: ).

9

While PHP isn’t involved in the process of establishing an SSL connection, you can use it to “force” https by redirecting all normal http traffic to https. For example:

//==== Turn on HTTPS - Detect if HTTPS, if not on, then turn on HTTPS:
function SSLon(){
    if($_SERVER['HTTPS'] != 'on'){
        $url = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
        header('Location: '.$url); exit;
    }
}//==== End -- Turn On HTTPS
10

You can also do this using htaccess and apache rewrite (my preference):

# Force Secure Admin Login
RewriteCond %{SERVER_PORT} !443
RewriteRule ^admin/ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

@Amy: I love the mini screenplay. Hopefully more users follow this new trend :smiley:

11

Here’s a really nice article on infoq.com about HTTPS connections: http://www.infoq.com/articles/HTTPS-Connection-Jeff-Moser

12

Ha ha. Glad you liked it. Not sure that I’ll every win an Oscar or Emmy, though!

In teaching, sometimes it helps to do role-playing and/or to explain things in more everyday terms.

Amy

13

Thank you for the links!!

Amy

14

Thanks of rall of the posts.

Okay, so to sum things up…

It sounds like the only thing I need to buy in order to provide secure communications between my users and my server is an SSL certificate with my web-host.

Right?

And it sounds like everything else is just a matter of how I program my PHP pages (i.e. when to access HTTPS).

Does that sound right?

On a side topic, if I get a web-hosting account that provides PHP, MySQL, and I buy an SSL certificate, then is there anything else I really need except lots of know-how on XHTML, CSS, PHP, and maybe MySQL?

I’m just looking for “deal-breaker” (i.e. things so expensive or so complicated or so inaccessible) that it would stop me from having a secure website.

Hope that makes some sense?!

Thanks,

Amy

15

If all you want is to avoid sending a password in plain text, you may want to consider using PHP HTTP Digest .

:slight_smile:

16

To understand secure connections you need to understand 2 principles.

  1. That an encryption method can require a different key to encode than to decode, without it being possible to figure out the decryption key if you are given the encryption key. This is called “public key cryptography”. With it, you can safely give out your encryption key to the whole world, but still be the only one that can read messages encoded with it. For two-way communication, each party makes their encryption key public but keeps their decryption key secret.

  2. That in order to be secure online you not only need to ensure your communication is encrypted (and nobody could get your decryption key) but you also need to ensure that the person you are communicating with really is who they say they are and they are not an impostor. Otherwise, the best encryption in the world is not going to help if you are actually speaking to the person who wants to steal your information. Thus, before communicating, a certificate exchange must be done. Public key cryptography allows ‘signing’ a certificate in such a way that anyone can tell if the signature in the certificate is authentic using a publicly available key, but nobody can create an authentic signature without a specially issued private key. In a client-server situation, the server doesn’t care who the client is, but the client cares who the server is. So the server has a certificate which the client can inspect to see if it is authentic (according to some trusted issuer of certificate signing keys).

Public key cryptography, which enables all this to happen, is described in this wikipedia article:

17

That part I was fairly comfortable with, but thanks for the detailed explanation!

  1. That in order to be secure online you not only need to ensure your communication is encrypted (and nobody could get your decryption key) but you also need to ensure that the person you are communicating with really is who they say they are and they are not an impostor. Otherwise, the best encryption in the world is not going to help if you are actually speaking to the person who wants to steal your information.

Very good point!!

Thus, before communicating, a certificate exchange must be done. Public key cryptography allows ‘signing’ a certificate in such a way that anyone can tell if the signature in the certificate is authentic using a publicly available key, but nobody can create an authentic signature without a specially issued private key.

Who/what check the certificates authenticity?

Me? My browser? Otehr?

When does that happen?

In a client-server situation, the server doesn’t care who the client is, but the client cares who the server is.

Why do you say that?

What if the client is a “bad guy”?!

Shouldn’t the server need to know something about who the client is?

So the server has a certificate which the client can inspect to see if it is authentic (according to some trusted issuer of certificate signing keys).

Public key cryptography, which enables all this to happen, is described in this wikipedia article:

Okay.

So how does this relate to my original post and concerns?

Do you agree that all I need is a web-hosting account and an SSL certificate?

Or is there something missing?

Thanks for your reply!!

Amy

18

The browser does in part. It ships with a list of trusted root authorities and will produce an alert advising you that the certificate is suspect if the certificate doesn’t have a trust chain leading back to one of the root trusted authorities. You can override it to tell it to trust a certificate anyway if you have verified it in some other way.

The part that the browser doesn’t do is to check who the certificate was issued to. As long as the certificate was issued to the current site it doesn’t care that you are on fakebank.com instead of bank.com as long as the certificate was issued to fakebank.com. That’s where the person using the browser has to click the padlock symbol to verify who the owner of the certificate is so as to make sure that it is who they expect it to be.

19

Your browser checks the certificate to see who issued it, and if it was issued by a Certificate Authority (ie company like Thawte, Globalsign etc) that it “trusts”, then it checks it against that company’s public key to ensure it is authentic.

If the certificate was not issued by any company your browser recognises (as in the case of a self-made key) or any other information appears suspect, then the browser will give a warning.

Note that just because a trusted Certificate Authority issued a certificate does not mean that the person you’re communicate can be trusted. It’s just a means of identifying that they are who they say they are, so it’s also important that the user checks the domain name or company name on the certificate and makes up their own mind about whether the company they are dealing with is trustworthy.

Why do you say that?

What if the client is a “bad guy”?!

Shouldn’t the server need to know something about who the client is?

Normally on the web, if the server needs to be able to verify who the client is, they do this once the secure session has already been opened. For instance, by requiring a login. The login details are all sent over the already secure channel. That is why I said the server doesn’t need to know who the client is in order to start the secure session.

This is a bit more user friendly, and privacy-friendly, than requiring all web users to have a certificate installed in their browser signed by a certain certificate authority (though some rare services do sometimes request a certificate from a client for security reasons).

Okay.

So how does this relate to my original post and concerns?

Do you agree that all I need is a web-hosting account and an SSL certificate?

Or is there something missing?

Yep, you’ll need an SSL certificate signed by a trusted Certificate Authority and issued for your actual domain name. An SSL certificate included free with your hosting package may not satisfy both those criteria.

You’ll need to get your host to enable HTTPS with that certificate. For Jane’s sake, make sure that the same content is not available via regular HTTP, and make sure none of your internal links, and links to things like scripts, stylesheets and images, lead to non-HTTPS sites. That’ll ensure her browser will never lead her to the same site, unprotected, or show a confusing warning about non-encrypted page elements.

There’s no special code to switch into or out of a secure connection except the “https:” at the beginning of a URL. Make sure the user is using a secure connection before logging in (ie, the login page should be included in those pages that are only accessible via “https:”).

20

Thanks, Stephen! Good stuff! :slight_smile:

Amy