What are our devices doing when we use the Internet?

Using the Internet has become something obvious for us. So obvious that we do not even think about many of the activities. What happens, and in fact what do our devices do when we use the Internet?

Consider a very simple scenario where we just want to look at some company’s website. Let’s call this company “Some Company.” Let’s assume that the website address of said company is known to us. Let it read https://www.jakasfirma.pl. Additionally, let the website of this company be static, that is, not performing any actions. Let it only present some content. Let’s split the web address into two parts. The first part before two slashes, that is “https” is a protocol name. This name tells our web browser how to communicate with the target server. We will describe the “https” protocol in a moment. But first we should discuss the second, or right-hand, segment of the web address after the two slashes, the www.jakasfirma.pl segment. We call this segment a “Fully Qualified Domain Name”, or FQDN for short. However, for simplicity’s sake, I will simply say “domain”.

What is a domain? In the previous episode of “IT In Simple Words” I told you that communication on the Internet takes place when you give the IP number of the server you want to contact. In this case the HTTP server, which is the Hypertext Transfer Protocol. IP number is in a way the equivalent of a phone number for devices on the network. Let’s imagine that every time we want to visit some website or send an e-mail we have to look in a kind of phone book with IP numbers first. Let’s recall how many websites we visit on a daily basis, how many applications we use multiple times a day. How often we jump from site to site, often without even knowing the sites. If we had to check IP addresses every time, the Internet would not be as easy to use as it is now. For this reason, to avoid such frequent checking of addresses, we have DNS service. DNS or Domain Name System is a kind of telephone directory with IP addresses. When you type in www.jakasfirma.pl in your browser, your operating system automatically sends a request to DNS that says “hey, what is the IP address of www.jakasfirma.pl”. And when DNS responds with the IP address, we don’t even notice and we will be directed to the page we wanted to see.

How does it work? Assuming the simplest scenario, our system will simply ask the configured DNS server for the address and if the server has already received such a query, it will simply give us an answer because it already knows it. But what will happen if the DNS server, which we are querying does not know the answer, i.e. does not know the address to some company? Here the situation gets a little more complicated. To understand this, we need to understand the concept of domains. Let’s look at the address www.jakasfirma.pl. This address consists of three parts, separated by dots. So we have four domains or subdomains in it. Yes, four, not three. The domain assigned with the abbreviation “pl” is called the “top-level domain”, but there is an even higher-level domain, called the “root domain”. The root domain is also shown in the address www.jakasfirma.pl. and is marked with a dot after the “en”. Practically all browsers allow to ignore this last dot, so today almost nobody remembers about it. Domains are hierarchical structures. The top-level domain “pl” is a subdomain or subdomain of the main domain, “jakasfirma” is a subdomain of “pl.”, “www” is a subdomain of “jakasfirma.pl.” and so on. So every domain except the main one is a subdomain of a higher-level domain. Let’s go back to the DNS query that our operating system sends to get the IP number for our site. The system sends a query to a known DNS server. The DNS server checks with its resources to see if the address is already known to it. If not, it sends a query to one of the main domain servers, i.e. to the one that is even higher than “pl”. The main domain server answers with the IP numbers of lower level DNS servers, in this case with the addresses

servers responsible for the “pl” domain. However, the DNS server we are querying does not stop there. After receiving addresses of DNS servers managing the “pl.” domain, it sends to one of them another query and in response receives the addresses of servers managing the “jakasfirma.pl.” domain. The process is repeated until the DNS server we are querying receives the final IP address assigned to the “fully qualified domain name” we requested. This whole process of sending successive queries and interpreting the responses sometimes takes several to tens of milliseconds.

You may of course ask the question, how is it, I will only get the server IP from the DNS? How will I know what the DNS server IP is? The answer to this question is quite simple. Well, the IP number of the DNS server must be known in advance. For this reason, when we connect our device to the network, the router will tell us what DNS to use. When you move your laptop from one network to another, you will also change the DNS server, which by the way may as well be installed on the router itself. We can also force some kind of custom DNS server address.

There is one more aspect about DNS as a whole system. This aspect concerns security and anonymity. DNS is a rather old technology. It was created in the days when Internet access was more for universities. Simply put, all our DNS queries and responses are sent in open text. In other words, anyone who is able to “sniff” our activity on the Internet and record communication, can without the slightest problem read the addresses of pages we asked DNS about. He can also find out the answers to our queries. There are technologies allowing to encrypt the content of queries and answers. For example, DNS-over-TLS or DNS-over-HTTPS. They allow us to encrypt the communication between our device and the DNS server and to verify that the DNS server is not crafted by a hacker. Using such a server with additional encryption, however, raises a question. “If even someone is eavesdropping on my Internet traffic, so what if the DNS query and response can’t be read, since I’ll still get to that page in less than a second and then find out what I was querying the DNS for?” And it will be a legitimate question, but only up to a point. If we are eavesdropped on at a stretch somewhere close to us, then indeed DNS encryption makes limited sense because if someone can see all of our online activity, they can also see the sites we visit. However, if we are eavesdropped on at some further distance, the attacker may know only a part of our activity, because packets travel along different routes. However, encrypted DNS query standards are still not very popular.

Let’s return to the URL in question, which is “https://www.jakasfirma.pl.” We already know how this URL is translated to an IP address. Our browser already knows where to direct the request. So what does this strange abbreviation “https” tell us. As I mentioned earlier, HTTP stands for Hypertext Transfer Protocol. It is a protocol that standardizes the communication of computers, the form of requests and responses. It is through this protocol that our browser sends a request to the server, which in turn, following HTTP standards, responds with text. A web page is basically a text that our browser is able to interpret and make an appropriate rendering based on it. About HTTP protocol dozens of books were written, but I would like to focus on “HTTPS” which is Hypertext Transfer Protocol Secure. This protocol in comparison to HTTP additionally includes encryption.

Knowing the IP of the server with the website of some company, our browser begins to establish a connection using the HTTPS protocol. While establishing such a connection the server will give us the so called “TLS certificate”. Such a certificate is basically a text file containing, among other things, the name of the server, the validity period of the certificate and the public key of the server. The public key specifies how our device should encrypt. Our device

encrypts the message using the public key. Such encrypted message, can be decrypted only by the holder of the private key. The private key resides on the server of some company’s website and should be well protected, because stealing such a key would give a hacker an opportunity to decrypt our communication with the server. After receiving TLS certificate, containing public key, our device, apart from other activities, generates random string of characters, encrypts it with public key and sends to server. The server is the only one in the world that has a private key, so it is able to read the message. The random string found in this message is de facto part of a new key that will be used for further communication. It is worth mentioning that this is not the only moment when both sides of the communication exchange random strings of characters. Instead, it is important to note that throughout the process, the parties agree on new keys and ciphers that will be understood by both parties, but will only be used for communication between the two devices and only for a limited time. So we can see that the TLS certificate that each new client receives in identical form is only used for a short time, specifically in the first stage called the “handshake”. After the handshake, that is, the exchange of temporary keys, the communication is understandable only to the two devices and cannot be read even by a third party who knows the server’s public key.

However, there is one problem. Well, everyone is able to generate for himself a pair of keys, i.e. public key and private key. And if so, how do we know that the public key we received is actually the public key of some company? How do we know that the key has not been intercepted somewhere on the way and that what we have received is a crafted key? Here the answer lies in the structure of the TLS certificate. TLS certificate contains information about domain to which it was issued, information about certificate validity period, public key and some other data. In addition, the TLS certificate is signed by a so called “certificate authority” which verifies that the company is the actual owner of the domain. If the company proves that it owns the domain, the CA will cryptographically sign the certificate of some company. Perhaps the CA’s certificate has also been signed with the key of a higher authority, so our browser will verify the signatures of more and more certificates until it finds a signature that it considers trusted. Trusted certificates can be viewed in your browser. These are usually certificates from so-called “root CAs”. These certificates do not need to be signed by anyone else. They are simply delivered with your browser or operating system. So if you visit a website and see a warning that the certificate is not trusted you know that your browser has not been able to find any digital signature connection between the certificate of the website you are connecting to and the certificate that your browser considers trusted. Let’s never underestimate such a warning, because it may just mean that a valid certificate was intercepted on the way and a crafted certificate is coming to us. If you accept the certificate you receive, you do it at your own risk. Hacker after crafting the certificate and our acceptance is able to see everything we do. For example, if you use a bank website, he would be able to check your account balance or see your password. Remember about this danger and never accept certificates, which we are not able to verify.

As you can see, simply typing a sequence of characters “https://www.jakasfirma.pl.” into the URL bar and pressing enter triggered an attack. and pressing enter, triggered a cascade of events, the end result of which was the display of the page and we considered a very simple example. Note that if we performed all the steps correctly and no one is trying to do something wrong, the whole process runs almost without our knowledge. However, it is important to be careful that we do everything correctly. If you enter the website address correctly, you should see a padlock in the URL bar. Then we can be sure that we are using the page we actually want to see. And even if someone is snooping, they are not able to deduce anything from what they see because the messages are encrypted.

What if we entered the address wrong? What if we accidentally entered the letter “m” instead of, for example, “rm” in the address or vice versa? These letters are similar and a quick glance may not be able to detect that. Maybe someone gave us such a wrong address on purpose? Unfortunately, such a method is still popular and, what’s worse, much more effective than capturing certificates. Hackers sometimes deliberately buy domains with very similar names to the real company websites. What’s worse, they get signed TLS certificates for those sites so the user doesn’t get a warning about an untrusted connection and even sees a padlock which only reinforces their false sense of security. The hacker is often the real owner of the domain, so he has the right to get a certificate for it. He could create a page that looks identical to the bank’s website, only at a different address and to improve credibility he bought a certificate. Such crafted website may stay on the Internet for a long time without impunity until someone reports it to appropriate organizations. For this reason, in such circumstances we should simply be very careful. Before giving out any logins or passwords always verify the domain, make sure that the address has been entered correctly. Never rush, because this is what people with bad intentions will provoke us to do. It is because of our haste that we most often fall prey to phishing. Nowadays, the use of cryptography has made attempts to break ciphers ineffective. Attacking an encrypted connection misses the target, so we became the target ourselves. The success of an attack is determined by psychological preparation as much as technical skills.

The Internet is not a safe place, despite many mechanisms available to make it a little more secure. But let’s not be under any illusions, it is up to us whether we will be fooled or not and no one will take responsibility for it. Let’s verify the domain, let’s not give in to time pressure and let’s treat with utmost suspicion everything that seems unusual to us. If something raises our doubts, let’s not act. Do not try to fight with someone who may be thousands of miles away, has no scruples and knows exactly what he is doing. Only our own reason and caution can protect us from irreversible damage, and sometimes one click is one click too many.