[Here is MY UNDERSTANDING of how the connection between my computer and another on the internet can basically be described to work, simplified GREATLY in order to make it so that a friend of mine can understand it. If I’m flat out wrong, let me know. The data that I’m trying to present is what LAYERS the connection request passes through.]
How the connection from your computer (the client) to another computer (the server) works:
Every connection starts with a series of requests – so that your connection can get where it needs to be.
These layers that your requests to the server pass through happen in a sequence that was designed right near the beginning of the internet, partially by the original framers of the internet, but the secure layer was designed mostly by Earthlink, who argued for the system we’re all used to now.
All connections are checked in the following sequence. Basically at the simplest level they can be described as:
direct -> secure -> insecure
The first layer, the direct access layer is most commonly called…
Secure Shell Layer (SSH) by which you can gain Shell access and is often accessed using FTP – file transfer protocol
By DIRECT is meant connecting directly to the IP address. The other connection layers below can pass through the DNS (Domain Name Servers) system, but this cannot. The server requires a username and password check for this kind of access. Sometimes it also requires that the client be at a particular IP address or it will disallow access.
If the client is connecting through a protocol that uses direct connections, such as by FTP or Shell, this is as far as the request goes and further protocols are skipped.
Ignore the next indented bit if you couldn’t care less about direct connections.
More about direct connections:
FTP gives direct access to the files there and very minimal controls (rename, change permissions, upload, download, etc).
Shell is the most basic connection that most servers allow – you’re basically deep in the bowels of the server, and have direct access to the applications on the server and allows commands to the server about those applications or commands directly to those applications. It’s very powerful. Such as “Reboot” or “Create a database, etc…” or even “delete every gosh darn thing”. You may be required to access Shell through very specific ways, such as direct connect through a specified port using a specified username from a specified IP address. With that much power, it should never be accessible otherwise.
If the request is for another connection type, then the connection moves to the next layer (secure).
If the site allows access, and the request is for HTTPS or HTTP, then the request goes to the next layer.
————————————-
The second layer, the secure layer is called…
SSL and HTTPS
SSL – Secure Socket Layer (secure encryption through two keys) and HTTPS Secure Hyptertext Transfer Protocol
When connected past this point, connections do not require direct connection – you can access through other computers, as with the internet. You can also connect directly if you want. This is why you can reach a website at it’s domain name or at its IP.
The server may require that communication occur via a specific port when going secure. If the server requires that HTTP connections be secure, then both ends attempt to create a secure connection. This requires that several steps (laid out carefully below) go smoothly so that the data gets encrypted and that the data can be unencrypted ONLY by the client and the server.
If that process goes smoothly, then there is a secure connection, and the request gets handled. If not, the request gets cut off and the client is shunted to the next layer – insecure.
If the server does not require secure connection and the connection is unsecure, it goes to the next layer – insecure.
Ignore this indented bit of you couldn’t care less about exactly how secure connections connect.
A lot more data about secure connections if you want it:
The secure connection process protects the data from tampering and eavesdropping. The reason it has to do this is because no matter how you connect, your data passes through dozens of other computers. If you don’t encrypt it, any of those computers could view it and some might have malicious intent. The process of secure transfer encrypts the data so that any of the servers between you and the other end only sees a random jumble.
In order to go secure, the client computer checks for a cypher that sits on both computers, the client and the server. It chooses the most complex of the cyphers shared by both computers. Then the server sends over its certificate to the client. Then the client checks the certificate against the authority to verify that it’s real, then the secure connection is generated by passing the data through an excryption sequence that consists of the session ID encrypted with the security certificate. The session ID is the ID for that specific connection. Since the session ID is a randomly generated number and the certificate itself is verified, the connection is considered secure and the data gets encrypted and transfered, and de-encrypted at the other end.
The encryption process is considered to be nearly infallible, as the security certificate cannot be faked, and the process of creating a certificate requires keys and checks. If the certificate is not real, or wasn’t issued by a real certificate authority (CA) then the web browser generates an error. The RSA key (RSA stands for the last names of the three men who invented this particular key-based encryption system in 1978, thus the RSA key) on the client server is used to generate a new file, an encrypted CSR, a Certificate Signing Request, which is the encryption that the authority uses to generate the CRT file – a CeRTificate file, which is based on running their CA file (Certificate Authority file) through a few passes then through the CSR generated by the server to generate a completely new file, which it calls the CRT. When you are connecting securely, the CRT and the session ID generate a session-specific encryption which is used by cypher agreed upon by both ends to create a completely secure connection.
All of the files mentioned above look like nothing more than a jumble of random characters to the average user. Their entire purpose is to force data through many passes, some of which are unique to the connection, in order to keep prying eyes out.
This is why we have to buy security certificates. Without them, there is no trusted third party to generate a certificate with. The server can generate the certificate file all by itself, called a “self-signed” certificate. Thus any connection can go secure without third party verification. But without the certificate authority saying “yes, we generated that certificate, and can prove it’s valid”, the web browser will raise an alarm that the connection MIGHT not be secure, and there won’t be a snazzy looking green bar or lock in the address bar on the browser.
What kind of level of “trust” the certificate provider ranks the server at (green bar? just a lock?) really has nothing to do with how secure the connection is. It mostly has to do with how much you paid the certificate authority and how thoroughly they investigated the business you’re connecting to. But, it really doesn’t matter how trusted the certificate provider really is: if the secure connection is screwy, the data will arrive completely incomprehensible. It would require so much work for anyone other than an expert to de-encrypt the intercepted data, requiring pass after pass of unencryption through various keys using various IDs that they’d never have access to. Which is why secure connections are usually considered completely secure.
————————————-
The third layer, the insecure layer is called…
TCP/IP and HTTP
TCP/IP layer is the insecure layer. I’m not sure it’s actually CALLED that, but I’ve only ever heard it refered to by the two protocols used to connect to that layer, TCP and IP – which means Transmission Control Protocol and Internet Protocol (connects you in general) and then the connection can use HyperText Transfer Protocol (gets you to your web pages and such).
Whatever you want to call it, this is the messy, standard way we connect to websites insecurely.
Read the indented section if you want to know more about connecting insecurely.
About insecure connections:
At this layer, the server rarely requires ports or IPs – it logs the data but doesn’t restrict access to data very much. The server may ban an IP that’s abused its access in the past. But so long as you’re allowed to connect, no certificates or verifications, and no usernames or passwords are required at this stage. Each file is still protected no matter what by the basic file permissions that pre-date the internet. Back when shared file systems were created, the basi permissioning system was implemented that any network connection must honor. On any computer, any file, before opening, that file is checked to see whether the user, the group or others can read, write or execute it. This permissioning is managed on UNIX machines through CHMOD (change mode). So, accessing permissions using CHMOD, even if a file is in a web-accessible folder, it can be uniquely protected from being viewable, write-able or actionable.
You can see how many back and forth “requests” and “responses” there need to be to actually get your computer connected to a distant server and looking at a specific file.
I hope that helped rather than confused the issue. It’s the simplest explanation I could give, even with more detailed data indented.
I want to hear back from you, to let me know if you see anything you KNOW is incorrect.