DEV Community: PGD

Linux Booting process

PGD — Mon, 22 Apr 2024 09:59:16 +0000

First of all, once a user turn the power on, the BIOS (Basic Input/Output System) is loaded from the ROM embedded on the motherboard. BIOS is responsible for initializing hardware such as screens, keyboard and testing the memory.
BIOS is not a part of OS (Operating System), but a component of hardware. After BIOS completes its tasks, the system control is passed to boot loader, which is responsible for loading and initializing operating system.
For BIOS/MBR system, the boot loader is stored in the boot sector, also known as MBR (Master Boot Record), which is the first sector of a disk, while for EFI ((Unified) Extensible Firmware Interface) system, the boot loader is stored in a partition of a storage (usually SSD or HDD), which is called ESP (EFI System Partition).
There are several boot loaders can be used

GRUB (GRand Unified Boot loader) for most of the Linux system
ISOLINUX for booting Linux system from removable disk
DAS U-Boot for booting Linux system in embedded devices

At the beginning of tasks the boot loader will do, the boot loader prompts the user to choose options for booting Linux or even alternative operating systems. In case of booting Linux, the boot loader is responsible for loading the kernel image and the initial RAM disk or filesystem (contains critical files and device drivers necessary for starting the system) into memory.

The boot loader is executed on the two distinct stage.
At the first stage, for BIOS/MBR system, the boot loader looks up partition table and finds a bootable partition. Once it finds a bootable partition, then it finds and loads the second stage boot loader, such as GRUB. For EFI/UEFI system, UEFI firmware reads the Boot Manager data which describes which UEFI application is to be launched and which partition the EFI exists. The UEFI firmware launches UEFI application, GRUB for instance, as defined in the boot entry in the firmware's boot manager. EFI/UEFI method is more versatile than the old BIOS/MBR method.
At the second stage, the GRUB allows the user to choose which operating system or kernel to be launched. Once an OS or kernel is selected, GRUB loads kernel on the memory and passes control to it. The kernel is usually compressed such that the first thing the kernel should do is uncompressing itself. And then, the kernel will analyze and check the state of hardware, and initialize hardware driver built into the kernel.

[TODO]

HTTPS note

PGD — Fri, 05 Apr 2024 09:51:21 +0000

SSL (Secure Socket Layer)

SSL is a strategy of communication on the web, developed by Netscape in 1995.
Since data transferred via web is composed of string, anyone can intercept and read the sensitive data. For security, SSL is used for encryption data to be transmitted.
SSL is implemented by what is called SSL certificate. SSL certificate contains information of identity of client and asymmetric key. One that is stored on the website or application server contains private key and the other contains public key. The public key is used for encryption of data, and private key is for decryption. The private key keeps secret in the server.

SSL handshake

SSL authentication is executed by a series of process called handshake.

The client, at first, initiates SSL handshake by sending "ClientHello" to the server. The "ClientHello" message contains information about security such as SSL/TLS version it can accept and cipher suites.
Then the server responds to the message and sends "ServerHello" to the client. The "ServerHello" message also contain information about which SSL/TLS version to use by the both parties of the communication.
After that, the server sends its Digital Certificates, verified by Certificate Authority (CA) such as www.SSL.com, to the client.
And then the browser validates the server's credential. Once it is verified, the client uses server's public key to encrypt a "premaster secret", a unique session key, and sends it back to the server.
The server decrypts the premaster secret with the server's private key. The server and client then compute the session key, which will be used as a symmetric encryption of every communication.

Components of SSL/TLS handshake

Asymmetric Encryption

There are private key and public key, which private key is for decryption, whereas public key is for encryption

Symmetric Encryption

A single shared by both client and server. It is used for encryption and decryption. Symmetric encryption is faster than asymmetric encryption. SSL/TLS handshake uses asymmetric encryption to share symmetric session key.

Digital Certificates

Digital Certificate is a digital document bind a public key to an entity like a website. Digital Certificate enables secure authentication on the internet. Digital Certificates are issued by Certificate Authorities (CAs) like www.SSL.com

Cypher Suite

Cypher Suite is a set of algorithm defines the cryptographic parameters for an SSL/TLS session. It includes key exchange methods, encryption ciphers, and hash functions.

Session Key

A session key is a temporary symmetric key generated by client and server. A session key is unique to each session. During the session, all data transmission is encrypted and decrypted by the temporary session key.

Types of SSL Certificates

Single-domain: is applied to a single domain.
Wildcard: is similar to single-domain, but it includes subdomains of the domain. For instance, a wildcard certificate includes sampledomain.com, api.sampledomain.com, auth.sampledomain.com, while a single-domain certificate could only cover the first.
Multi-domain: can apply to multiple unrelated domains.

Certificate

To verify whether the website is authenticated/certified or not (uncertified websites can be a evil website). An authenticated website has a unique personal certificate purchase from one of the CA's.

CA

Globally trusted companies, like GoDaddy, GeoTrust, VeriSign, etc. who provide digital certificate to the websites.

How a website get a certificate

Website owner first generates a public key and private key. He gives a Certificate Signing Request file (CSR) and his public key to the CA.
CA then creates a personal certificate based on CSR including domain name, owner name, expiry date, serial number, etc. and also adds an encrypted text (=digital signature) to the certificate and finally encrypts the whole certificate with the public key of the server and sends it back to the website owner.
This certificate is decrypted with the private key of the website owner and he installs it on the website.

The encrypted text is the digital signature of the CA. That text is encrypted by the private key of the CA and can only be decrypted by a public key of CA. When installing operating system or browser, root-certificates form many trusted CAs come with it. These root-certificates contain the public key of that CA provider which helps decrypt the signature.

HTTPS security split into 2 parts (handshake)

1. To validate the certificate of a website

1) When you enter the URL www.google.com, Google's server gives its public key and certificate (which was signed by GeoTrust) to the browser.
2) Browser ahs to verify the authenticity of the certificate, in other words, it's actually signed from GeoTrust or not. As browsers come with a pre-installed list of public keys from all the major CA's, it picks the public key of the GeoTrust and tries to decrypt the digital signature of the certificate which was encrypted by the private key of GeoTrust.
3) If it's able to decrypt the signature (which means it's a trustworthy website) then it proceeds to the next step, otherwise it stops and shows a red cross before the URL.

2. To create a secure connection

1) Google sends its public key when you enter www.google.com. Any data encrypted with the public key can only be decrypted by Google's private key which Google doesn't share with anyone.
2) After validating the certificate (phase 1 above), browser creates a new key, which is session key.
3) Browser encrypts a copy of session key and other request data with the Google's public key. Then it sends it back to the Google server.
4) Google's server decrypts the encrypted data using its private key and gets the session key (Someone says that the session key is never transmitted at all. It is established via a secure key negotiation algorithm. The premaster secret is not the session key. For now, I will understand the session key as a symmetric key), and other request data. Client and server are the only one that has the key. The key will be used for both decryption and encryption the data.
5) When google sends the data like requested HTML document and other HTTP data to the browser it first encrypts the data with the session key and browser decrypts with the other copy of the session key.
6) Similarly, when browser sends the data to the Google server, it encrypts the data with the session key which server decrypts on the other side.
The session key is only used for that session only. If the user closes the website and opens again, a new session key would be created.

TLS (Transport Layer Security)

TLS was derived from SSL, but it is developed not by Netscape. Since TLS is no longer associated with Netscape, the protocol name had been changed. By historical reason, SSL and TLS can be used interchangably.

What TLS does

Encryption: hides the data being transferred.
Authentication: ensures that the parties exchanging information are who they claim to be.
Integrity: verifies that the data has not been forged or tampered with.

TLS certificate

TLS certificate (a.k.a. SSL certificate) should be installed on the origin server of a website or application to use TLS. A TLS certificate contains important information about who owns the domain, along with the server's public key, both of which are important for validating the server's identity.

HTTPS (Hypertext Transfer Protocol Secure)

HTTPS simply uses SSL/TLS encryption on top of HTTP. HTTPS occurs based upon the transmission of SSL/TLS certificates, which verify that a particular provider is who they claim to be.
Any website, especially uses sensitive information or requires login credentials, should use HTTPS.

Port

HTTPS uses port 443.

In networking, a port is a virtual software-based point where network connections start and end. All network-connected computers expose a number of ports to enable them to receive traffic. Each port is associated with a specific process or service, and different protocols use different ports.

References

ApplicationContext, DispatcherServlet, ContextLoaderListener

PGD — Sat, 09 Mar 2024 08:34:30 +0000

A context indicates an instance of Spring bean container. If we want a DispatcherServlet to dispatch the request to beans annotated with @Controller (i.e., controllers), we should provide a context containing controller beans, in other words, we should pass the location of metadata of Spring context to DispatcherServlet so that it can generate his Spring context. Typically, Spring context DispatcherServlet has contains beans related to Web MVC, such as controllers or rest controllers (beans annotated with @Controller or @RestController).
Each DispatcherServlet has one Spring context its own. If you want some beans to be shared across your web application, it doesn't be achieved by registering beans on the DispatcherServlet context.
In that case, you can register your beans on the context included in ContextLoaderListener, which is so called bootstrap context since it is root of Spring contexts of web application. DispatcherServlet contexts are children of the bootstrap context. For a beans in parent context, it is visible to the child context, but not vice versa.
Once you register your beans into the bootstrap context in ContextLoaderListener, your DispatcherServlet can access the beans.

Registering ContextLoaderListener in web.xml:

<listener>
    <listner-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

<!-- By default, ContextLoaderListener uses XmlWebApplicationContext

<context-param>
    <param-name>contextClass</param-name>
    <param-value>org.springframework.web.context.support.XmlWebApplicationContext</param-value>
</context-param>

-->

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath*:spring-config/context-*.xml</param-value> <!-- For instance -->
</context-param>

ContextLoaderListener uses ServletContext to get the information where the metadata was placed.

Specifying context configuration location for DispatcherServlet

PGD — Thu, 07 Mar 2024 10:34:15 +0000

The DispatcherServlet is a front controller serving as a single point entry of request. In Spring MVC architecture, every request passes through DispatcherServlet. Once the DispatcherServlet receives the request then it recognizes the path, gets a controller mapped to the path, and lets the controller process the business logic.

Since DispatcherServlet is a front controller, which is a single point entry, it's the only servlet to register in web application context. We can register it by specifying inside of web.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
         version="4.0">

    <servlet>
        <servlet-name>dispatcherServlet</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>dispatcherServlet</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>
</web-app>

Also it's possible to tell DispatcherServlet where the Spring config file is by specifying an whose param name is "contextConfigLocation". If I have a Spring config file named "context-common.xml" on the root directory of web application, then I can specify the location as follows.

<init-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/context-common.xml</param-value>
</init-param

Also I can put the config file at the resources file and prepend "classpath:" at the config file path so that DispatcherServlet knows the config file places on the classpath.

DispatcherServlet lookups spring beans of controllers using WebApplicationContext. By default, its implementation the DispatcherServlet is using is org.springframework.web.context.support.XmlWebApplcationContext. That receives an XML configuration file for initial config file.
If I want to use a Java class annotated with @Configuration to configure Spring context, I have to say to DispatcherServlet that it should make use of other implementation of WebApplicationContext. AnnotationWebConfigApplicationContext is needed in order for the Spring Container to contain the configuration bean. It is possible to configure that in web.xml:

<servlet>
    <servlet-name>dispatcherServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </init-param>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>com.springmvc.demo.web.config.WebMVCConfig</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>dispatcherServlet</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

RMI (Remote Method Invocation)

PGD — Thu, 29 Feb 2024 03:11:32 +0000

RMI (Remote Method Invocation) is an API provided by J2EE platform that defines methods for applications in different systems (JVM in running) to communicate by invocating a method. It defines methods to communicate with different applications in distributed system environment.
RMI provides two objects, each called stub and skeleton. Both stub and skeleton are for building connection. A stub is the object for client-side application and a skeleton is for server-side application.
Once the client invokes a method of stub object, then the stub processes the following tasks.

Build a connection to the remote machine (JVM).
Route to the server.
Convert the parameter data of the remote method to call into a serialized data suitable for transmission (Marshaling).
Wait for result from the remote method.
Read the result or exception (Unmarshalling).
Return the result to the caller.

Once the server receives the signal, then the skeleton process the following tasks.

Unmarshall parameters.
Invoke the method providing the parameters.
Get the return from the method called and marshal it.
Send.

Distributed applications should perform the following process:

Locating remote method
Providing communication with the remote object.
Load class definition the method belongs to.