When the Internet was first rolled out as a publicly accessible medium, the HTTP protocol was designed to allow each point on the Internet, to communicate with every other point thereupon, by sending what are known as "HTTP headers". These are blocks of information, that tell the recipient what web page you're requesting, what character set it uses what browser you're using, and a raft of other administrative items that allow the communication to take place smoothly.
Because you don't have a direct connection to every server on the planet (which would see the planet covered in cables if you did!), what happens is that this information is used by "backbone servers", to route your request to the proper destination. This means that your HTTP headers need to be readable by those backbone servers, so that they can perform this task. Likewise, the HTTP headers your destination creates, to send the information you want back to you, need to be readable by those backbone servers, so that they can send the information to you after a successful request. Without those backbone servers, the Internet would be LOT slower, and possibly not even exist at all - they're handling billions of transactions every day.
Now comes the fun part.
Whenever content is sent from one point on the Internet to the other, it's attached to an HTTP header. In the past, that content was not encrypted, because when the Internet was first launched, very few people had both the technical knowledge
and the malicious intent to wreak havoc. Back in that more innocent era, there were far fewer opportunities for mischief, and it wasn't difficult to find out who was indulging in mischief, courtesy of that rarity of the requisite skills.
That time has long since passed into history, however.
Now, there are millions of people who know how to write JavaScript and PHP code, to mention two possible sources of mischief. Likewise, with database accesses using SQL, there are millions of people with SQL programming knowledge around the globe. That's even before you start to count the people who have acquired skills using the Microsoft development stack, using ASP.NET and the C# programming language, which provides even more opportunities for mayhem in malicious hands.
HTTPS is a means of stopping certain brands of mischief in its tracks, specifically, those brands of mischief that involve intercepting your communications, and using the data to impersonate you for devious or even criminal ends. Whilst parts of the HTTP headers have to remain readable to those backbone servers, they ignore content, and so, content can be encrypted, to prevent such details as your credit card numbers being intercepted and misused by everyone from 13 year olds in basements to Bulgarian organised criminals.
Quite simply, when your requests (and the content in the responses) are sent via HTTPS, the content is converted into what looks like gibberish or line noise to the uninitiated. Even seasoned cryptanalysts will have trouble working out what that content is, unless they have access to the sort of resources that are normally the remit of government intelligence agencies. Of course, the content is converted back to its original form once it arrives at your browser, so that you see your desired web page instead of gibberish.
The piece of software that performs this trick is called SSL - Secure Sockets Layer. It operates alongside the usual HTTP software, and its task is to encrypt content before the HTTP layer sends it out to the world at large. It does so transparently and seamlessly, meaning all you have to do, is let it perform its task, and your web browsing continues uninterrupted. Malicious interceptors of your messages, however, are left with nothing but some basic information about which website you requested, along with a pile of garbage data that is no use to them, because they don't know what keys were used to encrypt it.
The way this works is actually quite ingenious, and uses something called "public key cryptography". This is a system in which
two keys are required to transport a message. You, the recipient, have a
private key, known only to you (or more correctly, your web browser), and a
public key, which can be sent out to anyone. Your browser sends the public key to the server using HTTPS and the SSL, and the server then encrypts the data using your public key. But, because of the clever mathematics used to implement the system, that public key
cannot be used to
decrypt the message. Only you (or your browser) can do that using the
private key, which is never disseminated publicly.
Likewise, a banking system asking you to authorise financial transactions, can send you its public key, which can then be used by software at your end to scramble your bank details, but only the bank at the other end, using its private key, can unscramble the data and verify that you've sent valid account details and transaction authorisations.
Now, the question that many will be asking, is this. Why is Google pushing for HTTPS to become the default means of transmitting information between Internet users?
Quite simply, unsecured websites, including supposedly harmless or even frivolous ones, can be hijacked to perform malicious actions, by someone with the requisite knowledge and criminal intent. If that website accesses a database using SQL queries, for example, a technique called "SQL injection" can be used to insert malicious code into the website, which can then do everything from harvest the data and send it back to the attacker, or destroy the database altogether. Anyone with a reasonable level of understanding of PHP programming and MySQL database transactions can quickly produce malicious code if they are so minded, and attack websites using those technologies. Likewise, a proficient .NET and C# programmer can insert malicious code into a website using that technology stack as its underlying support, unless security measures have been implemented to prevent this.
Implementing your website as an HTTPS website, makes the job of malicious attackers that much harder. Because if there
are vulnerabilities on your website, the code containing those vulnerabilities is encrypted before it's sent to the end user, and an attacker has nothing but encrypted gibberish to work with.
There are, of course, ways for the sophisticated programmer to wreak havoc even in the presence of HTTPS, but sites likely to come under attack by that demographic usually have additional militarisation built in, along with ways and means of detecting intrusion attempts. Anyone trying to hack their way into an intelligence service or military website is going to find the Special Branch boys knocking on their door very quickly (or their equivalents in locations other than the UK), and I'm also not in the business of revealing the details of some of the nastier tricks that can be deployed by the malicious, because I don't want to find myself bundled into a van at 3am and whisked off to a secret interrogation centre. So anyone wanting to find out if there are alien spaceships hidden in the hangars of Area 51 will have to go elsewhere.
Suffice it to say that HTTPS keeps all but the seriously determined
and expert miscreants at bay. If you have reason to suspect that some of those expert miscreants are targeting
you, then you'll have already hired the people with the tools to keep them out, and spent a
lot of money militarising your system. Indeed, some of those expert miscreants end up being recruited to switch sides, and put their knowledge to use keeping other miscreants frustrated - "it takes a thief to catch a thief" and all that.
And with that, it's time to return to something more relaxing.
