Security

It's possible that you've become familiar with the term "time-based one-time passwords" (TOTP) in relation to "two-factor authentication" (FA) or "multi-factor authentication" (MFA).

However, do you really understand TOTP and how they work?

The Meaning of TOTP

"Time-Based One-Time Passwords” refer to passwords that are only valid for 30-90 seconds after they have been formed with a shared secret value and the current time on the system.

Passwords are almost always composed of six-digit sequences that are changed every thirty seconds. On the other hand, some implementations of TOTP make use of four-digit codes that become invalid after a period of 90 seconds.

An open standard is used in the TOTP algorithm, and this standard is detailed in RFC 6238.

What is a shared secret?

TOTP authentication uses a shared secret in the form of a secret key that is shared between the client and the server.

To the naked eye, the Shared Secret seems to be a string with a representation in Base32 that is similar to the following:

KRUGS4ZANFZSAYJAONUGC4TFMQQHGZLDOJSXIIDFPBQW24DMMU======

Computers are able to comprehend and make sense of information even if it is not legible by humans in the manner in which it is presented.

The client and the server both have a copy of the shared secret safely stored on their respective systems after a single transmission of the secret.

If an adversary is able to discover the value of the shared secret, then they will be able to construct their own unique one-time passcodes that are legitimate. Because of this, every implementation of TOTP needs to pay particular attention to securely storing the shared secret in a safe manner.

What is system time?

There is a clock that is integrated into every computer and mobile phone that measures what is referred to as Unix time.

Unix time is measured in terms of the number of seconds that have passed since January 1, 1970, at 00:00:00 UTC.

Unix time appears to be nothing more than a string of numbers:

1643788666

This small number, however, is excellent for the generation of an OTP since the majority of electrical devices using Unix time clocks are sufficiently synced with one another.

Implementations of the TOTP Authentication Protocol

The use of passwords is not recommended. However, you may increase security by combining a traditional password with a time-sensitive one-time password (TOTP). This combination is known as two-factor authentication or 2FA, and it may be used to authenticate your accounts, virtual private networks (VPNs), and apps securely.

TOTP can be implemented in hardware and software tokens:

•  The TOTP hardware token is a physical keychain that displays the current code on a small screen

•  The TOTP soft token is a mobile application that displays a code on a phone’s screen

It makes no difference whether you use software tokens or hardware tokens. The purpose of using two different forms of authentication is to increase the level of protection afforded to your online accounts. You have access to a one-time password generator that you may use during two-factor authentication to obtain access to your account. This generator is available to you regardless of whether you have a key fob or a smartphone with an authentication app.

How does a time-based one-time password work?

The value of the shared secret is included in the generation of each time-based one-time password (TOTP), which is dependent on the current time.

To produce a one-time password, the TOTP method takes into account both the current Unix time and the shared secret value.

The counter in the HMAC-based one-time password (HOTP) method is swapped out for the value of the current time in the time-based one-time password algorithm, which is a version of the HOTP algorithm.

The one-time password (TOTP) technique is based on a hash function that, given an input of indeterminate length, generates a short character string of fixed length. This explanation avoids getting too bogged down in technical language. If you simply have the result of a hash function, you will not be able to recreate the original parameters that were used to generate it. This is one of the hash function's strengths.

It is essential to keep in mind that TOTP offers a higher level of security than HOTP. Every 30 seconds, a brand new password is produced while using TOTP. When using HOTP, a new password is not created until after the previous one has been entered and used. The fact that the one-time password for HOTP continues to work even after it has been used for authentication leaves hackers with a significant window of opportunity to mount a successful assault.

Authentication using Multiple Factors (MFA)

A user must first register their TOTP token in any multi-factor authentication (MFA) system that supports a time-based one-time password before they can use the device to connect to their account.

Some TOTP soft tokens need the registration of a different OTP generator for each account. This effectively implies that if you add two accounts to your authenticator app, the program will produce two temporary passwords, one for each account, every 30 seconds. A single TOTP soft token (authenticator program) may support an infinite number of one-time password generators. Individual one-time password generators safeguard the security of all other accounts in the case where the security of an account is compromised.

To use 2FA, a secret must be created and shared between the TOTP token and the security system. The security system's secret must then be passed to the token.

How is the shared secret sent to the token?

Typically, the security system creates a QR code and requests that the user scan it using an authenticator app.

A QR code of this type is a visual depiction of a lengthy string of letters. The shared secret is, roughly speaking, part of this lengthy sequence.

The software will string the image and extract the secret when the user scans the QR code using the authenticator app. The authenticator program may now utilize the shared secret to generate one-time passwords.

When registering a TOTP token, the secret is only sent once. Many of the concerns about stealing the private key are alleviated. An adversary can still steal the secret, but they must first physically steal the token.

It works even when you're not connected to the internet!

To use the TOTP technique, you do not need an active internet connection on your smartphone or a physical key.

The TOTP token only needs to obtain the shared secret value once. The security system and the OTP generator may thus produce successive password values without needing to communicate. As a consequence, time-based one-time passwords (TOTP) operate even when the computer is turned off.

Facial recognition is a technology-based method of identifying a human face. Such a recognition system maps facial characteristics from an image or video using biometrics. To identify a match, it compares the information gained to a database of known faces. Facial recognition may aid in the verification of a person's identification, but it also presents privacy concerns.

The facial recognition industry is predicted to expand from $4 billion in 2017 to $7.7 billion in 2022. This is due to the fact that such technology holds several business uses including monitoring and marketing.

But here's where things become difficult. If you value your privacy, you undoubtedly want some say over how your personal information (your data) is utilised. The truth is, your "faceprint" is your personal information.

How does facial recognition work?

You might be adept at identifying people's faces. You probably have no trouble recognizing the face of a family member, friend, or acquaintance. You recognize their facial characteristics — their eyes, nose, and mouth and their facial movements.

That is exactly how a face recognition system operates but on a much larger, computational scale. Recognition technology sees data where you see a face. That information may be saved and retrieved. According to Georgetown University research, half of all American adults have their photos recorded in one or more facial-recognition databases that law enforcement authorities may consult should they wish to.

So, how does facial recognition really work? Although certain technologies differ, most follow a standard procedure:

•  A photograph or video of your face is obtained. Your face might be scanned alone or in a crowd. Your photo might show you gazing straight ahead or almost in a profile view.

•  The geometry of your face is scanned by facial recognition software. The distance between your eyes and the distance from your forehead to your chin are important considerations. The program recognizes facial landmarks — one system even recognizes 68 of them – which are all important in differentiating your face. As a consequence, your facial signature is created.

•  A database of known faces is matched to your facial signature, which is a mathematical formula. Consider the following: At least 117 million people in the United States have photos of their faces in one or more police databases. The FBI has access to 412 million of such pictures for searches, according to a May 2018 report.

•  A decision is made. Your faceprint could match one in a database bringing back a positive result.

How effective is facial recognition?

Experts are concerned that face recognition might result in incorrect identifications. What if a police agency wrongly identifies someone smashing a shop window during a riot as someone who was nowhere near the incident using facial recognition technology? How probable is it that such an incident will occur?

It depends. According to the National Institute of Standards and Technology tests, the top face recognition algorithm has an error rate of under 0.08% as of April 2020. This is a significant improvement from 2014 when the best algorithm on the market had an error rate of 4.1%.

According to a 2020 report by the Centre for Strategic & International Studies (CSI), accuracy is greater when identification algorithms are used to match persons to clear, static photos, such as passport photos and mugshots. When applied in this manner, face recognition algorithms achieved up to 99.97% accuracy on the National Institute of Standards and Technology's Facial Recognition Vendor Test.

In practice, however, accuracy rates are often lower. According to the CSI report, the Facial Recognition Vendor Test discovered that the mistake rate for one algorithm increased from 0.1% when faces were matched to high-quality mugshots to 9.3% when faces were matched against images of people caught in public. When individuals were not looking straight at the camera or were partly concealed by shadows or objects, error rates increased.

Another issue is ageing. According to the Facial Recognition Vendor Test, middle-tier facial recognition algorithms exhibited mistake rates that increased by roughly a factor of ten when attempting to match photographs of participants shot 18 years earlier.

Who employs facial recognition?

Many individuals and organisations utilise face recognition in a variety of settings. Here are a few examples:

Airport administration

In airports, facial recognition technologies can monitor persons entering and exiting. The technology has been utilised by the Department of Homeland Security to identify persons who have overstayed their visas or are under criminal investigation.

Product manufacturers of mobile phones

Apple originally employed facial recognition to unlock the iPhone X, and since, the technology has been carried over to all subsequent models. Face ID authenticates — it ensures that you are who you say you are when you access your phone. According to Apple, the likelihood of a random face unlocking your phone is one in one million.

Websites for social networking businesses

When you post a picture to Facebook, an algorithm is used to detect faces. If you wish to tag others in your images, the social media firm will ask you. If you answer yes, a connection to their profiles is created. Facial recognition on Facebook is 98 percent accurate.

Entrance businesses and restricted zones

Some businesses have abandoned security badges in favour of facial recognition technologies.

Religious congregations at places of worship

Face recognition has been used by churches to scan their congregations to see who is there. It's a fantastic method to keep track of regulars and irregulars, as well as to adapt contribution requests.

Campaign marketers and advertisers

When targeting groups for a product or concept, marketers often consider factors such as gender, age, and ethnicity. Even during a performance, facial recognition may be used to determine such audiences.

The use of facial recognition in police enforcement

Today, facial recognition databases play an important role in law enforcement. According to an Electronic Frontier Foundation investigation, law enforcement agencies frequently collect mugshots from jailed people and compare them to local, state, and federal face recognition databases.

Law enforcement organisations may use these mugshot databases to identify persons in images collected from a number of sources, including closed-circuit television cameras, traffic cameras, social media, and photos taken by police officers themselves.

According to the Electronic Frontier Foundation, police officers may also use their mobile phones, tablets, or other devices to take images of cars or pedestrians and instantaneously match their photos to the faces in one or more facial recognition databases.

In addition, police enforcement has utilised face recognition to identify persons who may be sought in connection with crimes at huge events such as concerts, sports events, or the Olympics.

Several face recognition technologies are available to the federal authorities. Its primary database, however, is the FBI's Next Generation Identification system. This collection comprises over 30 million images.

Conclusion

Opponents of face recognition systems argue that although they give some protection, it is not enough to outweigh a feeling of independence and freedom. Many people believe that the usage of these technologies violates their privacy, but their worries don't stop there. They also emphasise the dangers of identity theft. Even face recognition companies recognize that as the technology becomes more widely used, the probability of identity theft or fraud increases.

As with many emerging technologies, the enormous promise of facial recognition has its downsides, but manufacturers are working to improve the usability and accuracy of their systems every day.

Over the last several years, Chinese smartphones have gained a very lousy reputation when it comes to privacy, owing to a variety of factors including a lack of customer trust and the fact that global political events have not been particularly kind to China. China's worldwide image improved significantly in the mid-2010s, owing mostly to China's entry into the smartphone market and developments in 4G and 5G technology.

The market for smartphones is now one of the most rapidly developing areas of the technology sector worldwide. The number of mobile devices sold around the globe has skyrocketed from 100 million in 2007 to over 1.5 billion, which saw the advent of the smartphone revolution. Because smartphones are the most frequent way of connecting to the internet, companies that operate in this sector are vital to the development of the technology sector.

We saw the original Apple iPhone debut 14 years ago in 2007, which surely signaled the beginning of a new era of information. We've seen huge players like Samsung join the market throughout the years, and more lately, Chinese competitors like Huawei and Xiaomi have been eating up worldwide market share with their low-cost handsets. Moreover, Oppo and Vivo, which have a tiny but consistent market share and are even gaining popularity in the United States, should not be overlooked.

Apple has never been as successful in China as it is elsewhere, owing to the country's preference for domestic produce and local brand loyalty. Having said that, Apple has always been in demand there. Outside of China, however, Apple has controlled the smartphone industry for a long time, and the whole globe often lies in anticipation of their next news conference and the release of their next iPhone. For many years, market supremacy was exchanged between Apple and Samsung, with Samsung ruling the majority of the time.

However, the worldwide smartphone market has shifted recently. With such strong competition (Samsung, Xiaomi, Huawei) on the horizon, as well as Apple's extremely expensive pricing for its current products, Chinese competitors have adapted and established a stable market hold for the foreseeable future. Chinese smartphone manufacturers are now a serious rival for the established giants, offering the similar minimalist design approaches that Apple is renowned for, as well as entirely redesigning their marketing efforts. Finally, the US and EU markets are the most significant target markets for Chinese smartphones.

However, there seem to be severe privacy concerns that are impeding Chinese smartphones and their image.

What is the issue with Chinese smartphones?

There are a number of Chinese companies that are now producing smartphones on the market, with Huawei and Xiaomi being the most well-known and popular brands in countries other than China. The majority of customers may not be acquainted with some of the other "cheaper" businesses, such as Honor and Realme. There are a great number of other Chinese smartphone manufacturers, perhaps too many to list here.

What difference does it make whether you want to buy a Chinese smartphone or if you already own one, given the amount of political tension that exists between the United States and China? Unhappily, Chinese smartphones have been afflicted with a number of privacy and security issues, which may be broken down into the following categories:

•  Spyware already installed

•  Vulnerabilities when it comes to malware

•  Data theft

•  "Backdoors" in Hardware

•  Encryption-related flaws

Moreover, there are extra hazards involved with downloading particularly popular Chinese social networking applications, in addition to the malware that comes pre-installed on Chinese devices. Some examples of these risks include:

•  TikTok

•  WeChat

Conclusions for your smartphone's overall security

Let's not forget, now that we've covered the reasons why there is such a lot of bad buzz about Chinese smartphones and the privacy issues they pose, that a large part of this has to do with the political tensions that exist between China and the United States. Allegations of espionage, hacking, and danger to data have been made an extremely high number of times. In addition to that, there is an additional fact that is more significant for the typical user. Android, which has a far bigger user population and is thus more vulnerable to assaults because of the size of its user base, is the foundation upon which Chinese phones are built.

Let us highlight one thing: certainly, it is difficult to declare that these technologies are safe; but, the question is: what really is safe in this day and age? Should this make you, the regular person, think twice about purchasing a smartphone made in China? It is difficult to say what constitutes "security" at this time, and whether or not governments will try to gain access to your phone depends heavily on who you are and how sensitive your data is.

However, if you are concerned about your privacy, there are a few steps you should take for your own protection and peace of mind, regardless of the device you are using or the nation in which it was manufactured; the following is a list of these steps, which you may read below:

•  Always utilize a reputable virtual private network (VPN)

•  Consider the possibility that iOS is more secure than Android in general

•  Make sure your phone is protected by a strong password

•  Ensure that multi-factor authentication is used at all times

•  If at all possible, avoid sharing critical information online

•  Keep your smartphone's software up to date at all times

•  Never use suspicious applications or access third-party app marketplaces

Most of web3's security is based on the blockchain’s unique ability to be resistant to human intervention. However, because of the associated feature of finality, where transactions are generally irreversible, these software-driven networks are an attractive target for attackers. Likewise, as the value of blockchains — the distributed computer networks that underpin Web3 — grows, they become increasingly appealing.

While web3 differs from previous web iterations, we have seen similarities with prior software security patterns. In many cases, the most serious issues stay unchanged. Advocates, whether they are builders, security teams, or everyday crypto users, can better secure themselves, their projects, and their wallets by learning these areas. Based on people's experiences, we've compiled a list of recurring themes and predictions.

Chase the money

Typically, attackers seek to maximise their return on investment. Because the potential return is bigger, they may devote more time and effort to attacking protocols with a higher "total value locked," or TVL for short.

Hacking groups with the highest amounts of resources are more likely to target high-value systems. New, more valuable exploits are also more likely to target these important targets.

Low-cost assaults, such as phishing, will never go away, and we expect them to become more prevalent in the near future.

Fixing a hole

As developers learn from tried-and-true assaults, they can improve web3 software to the point where it is "safe by default." This frequently entails tightening up application programming interfaces (APIs) to make it more difficult for people to add vulnerabilities by mistake.

Because security is always a work in progress, and nothing is ever immune to hacking, defenders and developers may make attacks more expensive by removing most of the low-hanging fruit for attackers.

The success of the following attacks may be considerably reduced as security policies and tools improve: control attacks, price oracle manipulation, and re-entry problems.

Platforms that cannot provide "perfect" security will have to employ exploit mitigation methods to decrease the possibility of losses. This can deter attackers by lowering the "benefit" or possible benefit component of their cost-benefit analysis.

Attack classification

Attacks on various systems can be categorised based on their similarities. The sophistication of the attack, the extent to which attacks can be automated, and the preventive measures available to fight against them are all defining aspects.

The following are some of the types of assaults that users have observed in the most recent hacks. We've also included our thoughts on the current threat landscape and what we anticipate from web3 security in the future.

Top predators in APT Operations

Advanced attackers, often known as advanced persistent threats (APTs), are a security nightmare. Their motivations and talents vary significantly, but they are usually well-endowed and, as the term suggests, persistent; unfortunately, they are likely to constantly be present. APTs carry out a wide range of operations, but these threat actors are the most likely to actively assault a company's network layer to achieve their objectives.

We know that certain advanced groups are actively pursuing web3 initiatives, and assume that there are others who have yet to be discovered. The people behind the most serious APTs typically reside in countries with no extradition accords with the US and EU, making it harder to punish them for their actions. Lazarus Group, a North Korean gang responsible for the greatest сryptocurrency heist on record, is one of the most well-known APT attackers.

We anticipate that APTs will continue to operate as long as they can monetize their activities or achieve various political objectives.

Social engineers engage in customer phishing

Phishing is a well-known and prevalent issue. Phishers attempt to trick their victims into falling into a trap by delivering bait messages over numerous channels such as instant messengers, email, Twitter, Telegram, Discord, and compromised websites. If you look through your spam folder, you're sure to find hundreds of efforts to deceive you into disclosing personal information or stealing money.

Phishing efforts are targeting web3 users now that it allows people to directly exchange assets like tokens or NFTs quickly. These assaults are the simplest way for persons with little to no technical knowledge to profit from cryptocurrency theft. They remain, however, a viable technique for organised teams with serious goals or advanced groups looking to undertake large-scale wallet-emptying attacks, such as website hijacking.

We anticipate a rise in these attacks because phishing is inexpensive and phishers seek to adapt to and circumvent the most recent security features. Increased education and awareness, better filtering, clearer warning banners, and tighter wallet restrictions can all help to improve user protection.

Vulnerabilities in the supply chain are the weakest links

Third-party software libraries expose a significant surface for attack. This has long been a security concern for pre-Web3 systems, as evidenced by the log4j hack that compromised a popular web server’s software in December. Attackers will search the Internet for known vulnerabilities in order to locate unpatched flaws to attack.

Although the imported code was not built by your engineering team, it must be maintained. Teams must keep an eye out for vulnerabilities in their software components, ensuring that updates are deployed, while staying up to speed on the dynamics and progress of the projects on which they rely. The real and immediate cost of exploiting web3 software vulnerabilities makes communicating these issues to library users challenging. The decision on how and where the teams communicate this in a way that does not mistakenly jeopardise users' monies is still pending.

We expect Supply Chain Vulnerabilities to rise as the dependency and complexity of software systems grow. Random hacking assaults are expected to rise as well until solid, standardised ways for exposing web 3 security flaws are created.

GPS devices have been made accessible to a wider market as technology advances, and the degree to which our daily lives rely on precise location and timing has also increased. For tourists to navigate effectively from one location to another, the use of a global positioning system (GPS) has become standard.

Businesses and people now have access to possibilities that were previously unavailable because of GPS. On the other hand, this is not always a positive thing since spoofing might make GPS systems susceptible to cyber assaults. Let's find out the main things about spoofing and how to keep your GPS safe.

How does GPS spoofing work and what is it?

GPS signal spoofing occurs when an attacker imitates the original GPS signal by substituting a phoney GPS satellite signal. The "false" signal indicates a change in location, navigation, or time to the recipient.

Have you ever driven to the local mall, but your GPS said that you were at the library? If your GPS has ever told you that you are at an incorrect location, you have likely been the victim of GPS signal spoofing.

How does it work?

To understand how spoofing works, we must first understand how global navigation satellite systems operate. The satellites transmit communication signals to our devices while orbiting the Earth in a medium earth orbit at a height of approximately 20,400 kilometres.

Satellite signals are sometimes rather weak as they must travel such a long distance to reach your device. GPS communications are not encrypted and may be read. As a result, they are an apparent target for anybody wishing to record, transmit, or modify them.

The terrestrial radio transmitter imitates GPS signals with a signal strength that exceeds what the genuine system can handle in a GPS spoofing attack. This replaces authentic GPS signals with fake ones.

But how can a GPS signal be tampered with? This usually includes the utilisation of a GPS spoofing device or spoofing technology, such as an app. They change GPS signals; to spoof, the transmitter must be near the GPS-enabled device. It then imitates the signal to fool the GPS receiver into reporting a different location.

Spoofing technology was formerly difficult to get a hold of. It was once a costly technology only accessible to the military. Now, a transmitter of this kind is already widely accessible. GPS jammers can be found online for as little as 100 USD. As a result, nearly anybody can impersonate GPS signals.

Who falsifies GPS signals and why?

Any satellite navigation-based technique is susceptible to spoofing. The technique of spoofing is practically free, readily accessible, and immensely popular. Virtually everyone uses spoofing, from privacy advocates to Uber drivers, and teenagers.

Since GPS is essentially accessible to everyone, its security has become a big problem. There are several reasons to alter the GPS signal. These consist of:

•  Accessibility to country characteristics

Some individuals use spoofing to alter their device's receivers in order to get access to country-restricted material, services, games, applications, and even television programs and movies.

For instance, certain programs on Hulu, Netflix, and other streaming services are only accessible in particular regions. Since it is impossible to fly to another country in order to view programs, spoofing allows you to modify your true location and access country-restricted content. Many individuals utilise VPNs for this reason.

•  For military purposes

Initial plans were for the military to use GPS equipment. Ironically, the military was the first to falsify GPS. The majority of armed forces may utilise GPS to simulate their position and conceal their activity. For tactical navigation, guided weaponry, and command and control operations, the military may also perform GPS spoofing assaults.

•  To avoid motion tracking and conceal locations

Numerous individuals use spoofing to generate a false GPS position, preventing applications from precisely tracking their activities. Most individuals use this to keep some sense of control over their data by instructing their applications to show an incorrect location.

Additionally, teenagers use spoofing to conceal their whereabouts from their parents. This is how easy spoofing has become.

•  To conceal unlawful conduct

Criminals may also employ spoofing to conceal fraudulent acts such as kidnappings, car thefts, and evidence tampering, or to induce public panic by causing accidents by interfering with automobiles. They may even fake a GPS to send victims to online or physical danger zones.

GPS safety suggestions

Here is some advice on how to prevent GPS spoofing attacks:

•  Install phone antennae

Install bogus antennae in a visible location, away from the genuine ones. This guarantees that spoofing attacks do not disrupt real transmissions. A reasonable distance should be at least 300 metres.

•  Carefully consider where to place your antenna

The antenna's optimum placement should offer an unobstructed view of the sky. Signals from the ground or neighbouring public areas are blocked by buildings and other objects.

Install antennas in areas where they are not visible to the general public, or use barriers such as plastic fencing to hide their position while not interfering with GPS signals.

•  Follow internet hygiene guidelines

Individuals and companies should change and update passwords regularly, install security patches and updates, utilise firewalls and virus protection, and consider adopting multi-factor authentication and other cyber defences to avoid spoofing attacks.

•  Turn off any GPS-enabled gadgets that are not in use

Individuals and businesses that utilise GPS-enabled devices should keep them turned off when not in use. This will keep spoofing attempts at bay.

Install two or more antennae at opposite ends of a building or ship to identify faults and switch to backup navigation systems instantly.

GPS monitoring and location sharing offer significant privacy risks. GPS spoofing may be very dangerous for people, corporations, and governments. Regardless, it enables users to safeguard themselves against security risks and dangers. So, a balance must be achieved.

1. Basic Information about SSL

1.1 What Are ‘Certificates’ and Why Are They Needed?

Certificates are text files on a web server, the placement and content of which confirms the identity of the responsible owner of a web resource. Owner confirmation is carried out by specially authorized companies or divisions of an organization – Certification Centers (also referred to as the CC, Certificate Authority, CA).

Additionally, certificates contain the public key required to establish an encrypted connection to work on a network in order to prevent data interception by intruders. The protocols by which this connection is established end with the letter "S", from the English word "Secure" — see HTTP(S), FTP(S), etc. This means that standard internet protocols, such as HTTP and FTP, are used over an encrypted TLS connection, whereas ordinary messages are exchanged over TCP/IP without encryption. TLS (which stands for Transport Layer Security is a protocol that ensures secure data transfer based on SSL (Secure Sockets Layer), which is another cryptographic protocol. This uses asymmetric cryptography to authenticate exchange keys so that a session can be established, symmetric encryption to further preserve the confidentiality of the session, and the cryptographic signature of messages to guarantee the delivery of information without loss. Despite the fact that it is the only TLS protocol that is actually used, due to habit, the entire family of these protocols is called SSL, and the accompanying certificates are SSL certificates.

The use of SSL certificates primarily allows you to prevent data theft by using clones of sites of well-known services, when attackers duplicate the main pages of said sites, employ similar domain names, and forge personal information forms. The user may input personal information about themselves, their documents, and payment details on fake websites. As a result, users' personal information may subsequently be used to gain unauthorized access to other resources or social networks so it can be resold, or used to steal funds from a bank account. Service owners can help customers avoid these problems by configuring HTTPS on their resource and demonstrating the authenticity of their web pages to their users directly in the browser address bar.

As mentioned above, TLS/SSL is used to encrypt traffic from the client to the web server, and this prevents intruders from intercepting traffic on public unsecured networks.

1.2 How Do They Work?

When it comes to TLS /SSL, three parties are involved: the client – the consumer of services or goods on the internet; the server – the provider of these services or goods; and the Certification Center, whose duties include ensuring that the domain name and resource belong to the organization specified in the registration information of the certificate.

The TLS/SSL algorithm works as follows:

1.   The owners of the service contact the Certification Center through partners and provide information about themselves.

2.   The Certification Center makes inquiries about the owners of the service. If the primary information is verified, the Certification Center issues the owners of the service with a certificate which includes the verified information and a public key.

3.   The user launches a browser on a personal device and goes to the service page.

4.   The browser, along with other standard operations, requests the SSL certificate while the service page is loading.

5.   The service sends the browser a copy of the certificate in response.

6.   The browser checks the validity period and validity of the copy of the certificate using the Certificate Centers’ pre-installed root certificates. If everything is approved, the browser sends the corresponding response to the service, signed with the client's key.

7.   The service receives confirmation of the client’s verification with their digital signature and they begin an encrypted session.

Session encryption is carried out using PKI (Public Key Infrastructure). PKI is based on the following principles:

1.   There is a related pair of non-interchangeable control sequences of almost random characters called keys: public or public and private, also referred to as private.

2.   Any dataset can be encrypted with a public key. Because of this, the public key can be freely transmitted over the network, and an attacker will not be able to use it to harm users.

3.   The private key is known only to its owner and can decrypt the received data stream into structured information that has been encrypted with a public key paired with it. The private key should be stored on the service and used only for local decryption of messages that have been received. If an attacker is able to gain access to a private key, then procedures for revoking and reissuing the certificate must be initiated to make the previous certificate useless. A leak of a private key is called a compromise.

An SSL certificate from a Certificate Authority is one way of distributing a server’s public key to clients in unsecured networks. After verifying the validity of the certificate, the client encrypts all outgoing messages with the public key attached to the certificate and decrypts incoming messages with the private one, thereby ensuring a secure communication channel.

1.3 Who Releases Them?

Certificates are issued by Certification Centers upon the request of customers. The Certification Center is an independent third–party organization that officially verifies the information specified in a certificate request: i.e. whether the domain name is valid, whether a network resource with this name belongs to a specific company or individual to whom it is registered; whether the site of the company or individual to whom the SSL certificate was issued is genuine, and other checks. The most famous international Certification Centers are Comodo, Geotrust, GoDaddy, GlobalSign, Symantec. The root SSL certificates of these Certification Authorities are pre-installed as trusted in all popular browsers and operating systems.

It is often more cost-effective to purchase certificates not directly from the Certification Center but from their partners instead, as they offer wholesale discounts. In Russia, many companies and hosting providers that have their own tariffs for the SSL certificate service sell certificates from well-known Certification Centers.

2. Advanced Information about Certificates

2.1 Which Crypto Algorithms Are Used?

The following algorithms are used to establish a secure connection:

• Encryption algorithm
• Hashing algorithms
• Authentication algorithms

The most commonly used encryption algorithms for cryptographic operations in TLS/SSL are combinations of the algorithms RSA (an initialism of the names of the creators Rivest, Shamir and Adleman), DSA (which stands for Digital Signature Algorithm, patented by the National Institute of Standards and Technology of the USA) and several variations of the Diffie–Hellman algorithm or DH, such as a one-time DH (Ephemeral Diffie–Hellman, EDH) and DH based on elliptic curves (Elliptic curve Diffie–Hellman, ECDH). These Diffie-Hellman variations, unlike the original algorithm, provide progressive secrecy, i.e. when previously recorded data cannot be decrypted after a certain amount of time — even if it was possible to obtain the server's secret key — because the original parameters of the algorithm are generated again when the channel is re-established after a forced break when the connection has timed out.

Hashing algorithms are based on a family of mathematical functions for calculating the hash SHA (Secure Hash Algorithm). The hash function allows you to convert the original data array into a string of a certain length, and this length determines the amount of processing time and the computing power required. All encryption algorithms today support the SHA2 hashing algorithm, most often SHA-256. SHA-512 has a similar structure, but in it the word length is 64 bits rather than 32, the number of rounds in the cycle is 80 rather than 64, and the message is divided into blocks of 1024 bits rather than 512 bits. Previously, SHA1 and MD5 algorithms were used for the same purpose, but today they are considered vulnerable to attack. Modern services use keys 64 bits long and higher. The current version of the SHA-3 algorithm (Keccak), uses an amount necessary to verify the integrity of the transmitted data — MAC (Message Authentication Code). The MAC uses the mapping function to represent message data as a fixed length value, and then hashes the message.

In modern versions of the TLS protocol, HMAC is used (Hashed Message Authentication Code), which uses a hash function immediately with a shared secret key. This key is transmitted along with the flow of information, and to confirm authenticity, both parties must use the same secret keys. This provides greater security.

The General Algorithm of SSL Operation

1.   Handshake protocol. The connection confirmation (handshake) protocol is the order of operations performed directly during the initialization of the SSL connection between the client and the server. The protocol allows the server and client to carry out mutual authentication, determine the encryption algorithm and MAC, as well as secret keys to protect data during a further SSL session. The handshake protocol is used by participants at the stage before data exchange. Each message transmitted as part of the handshake protocol contains the following fields:

• Type is the category of messages. There are 10 categories of messages.
• Length refers to the length of each message in bytes.
• The content is the message itself and its parameters.

During the handshake, the following stages take place:

1.1 Determination of supported algorithms. At the first stage, the connection between the client and the server is initiated and the encryption algorithms are selected. First, the client sends a welcome message to the server, before entering response-waiting mode. After receiving the client's welcome message, the server returns its own welcome message to the client to confirm the connection. The client's welcome message includes the following data:

• The maximum SSL version number that the client can support
• A 32-byte random number used to generate the master secret
• Session ID
• A list of cipher suites
• A list of compression algorithms

The format of the list of cipher suites is as follows:

<1>_<2>_<3>_<4>

Wherein lies:

• The name of the protocol, for example, "SSL" or "TLS".
• Key exchange algorithm (with an indication of the authentication algorithm).
• The encryption algorithm.
• Hashing algorithm. For example, the entry  "SSL_DHE_RSA_WITH_DES_CBC_SHA" means that the fragment "DHE_RSA" (temporary Diffie-Hellman with RSA digital signature) is defined as a key exchange algorithm; the fragment "DES_CBC" is defined as an encryption algorithm; and the fragment "SHA" is defined as a hashing algorithm. As will be discussed later in TLSv1.3, the key exchange and encryption protocols are combined into an authenticated encryption algorithm with attached data (AEAD), so the entry there will be shorter. Example: TLS_AES_256_GCM_SHA384. The server response includes the following fields:
• The SSL version number. On the client side, the lowest version number supported by the client and the largest version number supported by the server are compared. Depending on the server’s settings, selection priority can be given to either the client or server.
• A 32-byte random number used to generate the master secret.
• Session ID.
• A set of ciphers from the list of ciphers supported by the client.
• Compression method from the list of compression methods supported by the client.

1.2 Server authentication and key exchange

At the second stage, all messages are sent by the server. This stage is divided into 4 steps:

• The sending of a digital certificate to the client so they can use the server's public key for authentication purposes.
• Key exchange on the server. Depending on the established algorithm, this step may be skipped.
• Client certificate request. Depending on the settings, the server may require the client to send their own certificate.
• A message confirming that the server authentication and key exchange stage is complete, before moving on to the next stage.  

1.3 Client authentication and key exchange:

At the third stage, all messages are sent by the client. This stage is divided into 3 steps:

• The sending of the certificate to the server — if the server requested it (this depends on the established algorithm). If the algorithm includes this, the client can authenticate on the server. For example, in IIS, you can configure mandatory authentication of the client certificate.
• Client key exchange (Pre-master-secret) – the sending of the master key to the server, which will later be encrypted using the server key. The client knows the master key and in case of server substitution will be able to terminate the connection.
• Signing a random number to confirm ownership of the certificate's public key. This stage also depends on the algorithm chosen.

1.4 Server shutdown

At the fourth stage, messages are exchanged directly and errors are monitored. If an error is detected, the alarm protocol comes into effect. This stage consists of exchanging session messages: the first two messages come from the client, and the last two come from the server.

2.   The Key Generation Process

To ensure the integrity and confidentiality of information, SSL requires six encryption secrets: four keys and two values of the initialization vector (IV, see below). The information’s authenticity is guaranteed by an authentication key (for example, HMAC). The data is then encrypted by a public key, and data blocks are created based on IV. The keys required by SSL are unidirectional, so when a client is hacked, the data obtained cannot be used to hack the server.

3.   Record Agreement (Record Protocol)

The recording protocol is used after a connection between the client and the server has been successfully established, and when the client and server have passed mutual authentication and have determined the algorithm they will use to exchange information about the algorithms used. The recording protocol implements the following functions:

• Confidentiality by using the secret key defined at the handshake stage;
• Integrity by analyzing the MAC defined at the handshake.

4.   Alarm Protocol

When the client and server detect an error, they send a message recognizing this. If it is a critical error, the algorithm immediately closes the SSL connection, and both sides first delete the session details: the identifier, secret, and key. Each error message is 2 bytes long. The first byte indicates the type of error. If the connection fails, the value is 1, while if a critical error is detected, it is 2. The second byte indicates the nature of the error.

2.2 Versions of SSL (SSL, TLS) — and How They Differ

During the initial installation of a secure connection between the client and the server, the protocol is selected from those supported by both sides from the set of SSLv3, TLSv1, TLSv1.1, TLSv1.2 or TLSv1.3.

Earlier versions of the SSL protocol are not used. The SSLv1 version was never made public. The SSLv2 version was released in February 1995, but it contained many security flaws that led to the development of SSLv3. Various IT companies have begun to attempt to implement their own versions of secure data transfer protocols. In order to prevent disunity and monopolization in the field of network security, the international community of designers, scientists, network operators, and providers (The Internet Engineering Task Force [IETF]), which was created by the Internet Architecture Council in 1986, is involved with developing protocols and organizing the internet, specifically regarding the standardized TLS protocol version 1, slightly different from SSL 3.0.

The technical details of the protocol are recorded by the release of a document called RFC (Request for Comments, working proposal). These documents can be found on the IETF website: www.ietf.org/rfc/rfcXXXX.txt , where XXXX is a four-digit RFC number. Thus, the TLSv1 version is fixed in RFC 2246, the TLSv1.1 version is fixed in RFC 4346, the TLSv1 version.2 in RFC 5246, and the TLSv1 version.3 in RFC 8446. In addition, RFC 3546 defines several extensions for cases when TLS is used in systems with limited bandwidth, such as wireless networks; RFC 6066 defines a number of additional TLS changes made to the extended client greeting format (presented in TLSv1.2); RFC 6961 defines a method for reducing traffic when a client requests information about the status of a certificate from the server; and, finally, RFC 7925 defines what happens to TLS (and DTLS) when it is used in IoT (Internet Of Things) to exchange data between hardware and other physical objects without human intervention.

As mentioned above, the TLSv1 protocol was released as an update to SSLv3. RFC 2246 states that "the differences between this protocol and SSLv3 are not hugely significant, but they are significant enough to exclude interaction between TLSv1 and SSLv3."

In contrast to the TLS Version 1.0, the TLSv1.1 protocol provides:

• Added protection against attacks using CBC (Cipher Block Chaining), when each block of plaintext is associated with the previous block of ciphertext before encryption.
  1.   The implicit initialization vector (the original pseudorandom number initiating the calculation of the further cipher, IV) was replaced by an explicit one which is not secret, but nonetheless cannot be predicted in a reasonable timeframe.
  2.   A change in the handling of block filling errors when a data packet is expanded to a fixed block size.
• Support for registering server IP address parameters and other network information.

The TLS 1.2 protocol is based on the TLS 1.1 specification. This is the most common at the moment. The main differences include:

• The combination of MD5–SHA-1 hashing algorithms in a pseudorandom function (PRF) has been replaced by the more secure SHA-256, with the possibility of using a set of ciphers, the specified function.
• The hash size in the finished message has become at least 96 bits.
• The combination of MD5–SHA-1 hashing algorithms in the digital signature has been replaced by a single hash agreed upon during the handshake, which is SHA-1 by default.
• The implementation of the function of selecting encryption and hashing algorithms for the client and server.
• The extension of support for authenticated encryption ciphers used mainly for Galois/Counter mode (GCM) and CCM mode for Advanced Encryption Standard (AES).
• The addition of TLS extension definitions and AES cipher suites.
• The ending of backward compatibility with SSLv2 as part of the 6176 RFC. Thus, TLS sessions have ceased to negotiate the use of SSL version 2.0.

The TLS 1.3 protocol is based on the TLS 1.2 specification. Internet services are gradually transitioning to this protocol. The main differences include:

• The separation of key matching and authentication algorithms from cipher suites.
• The ending of support for unstable and less-used named elliptic curves.
• The ending of support for MD5 and SHA-224 cryptographic hash functions.
• The need for digital signatures even when using the previous configuration.
• The integration of the HMAC-based key generation function and a semi-ephemeral DH sentence.
• The introduction of support for a one-time resumption of the receive-transmit session (Round Trip Time or 1-RTT) handshakes, and initial support for zero time for resuming the receive-transmit session (the name of the 0-RTT mode).
• Session keys obtained using a set of long-term keys can no longer be compromised when attackers gain access to them. This property is called perfect direct secrecy (PFS) and is implemented through the use of ephemeral keys during the DH key agreement.
• The ending of support for many insecure or outdated functions, including compression, renegotiation, ciphers other than AEAD-block encryption modes (Authenticated Encryption with Associated Data), non-PFS key exchange (including static RSA key exchange and static DH key exchange), configurable EDH groups, elliptic curve point ECDH format negotiation, encryption modification specification protocol, UNIX time welcome message, etc.
• The prevention of SSL or RC4 negotiation that was previously possible to ensure backward compatibility.
• The ceasing of use of a record-level version number and fixing the number to improve backward compatibility.
• The addition of the ChaCha20 stream cipher with the Poly1305 message authentication code.
• The addition of digital signature algorithms Ed25519 and Ed448.
• The addition of the x25519 and x448 key exchange protocols.
• The addition of support for sending multiple responses to the Online Certificate Status Protocol, OCSP.
• The encryption of all confirmations of receiving and transmitting a block of data after calling the server.

2.3 What Is PKI (Public Key Infrastructure)?

Public Key Infrastructure (PKI) is a system of software, hardware and regulatory methods that solve cryptographic tasks based on a pair of private and public keys. The PKI is based on the exclusive trust of the exchange participants in the certifying center in the absence of information about each other. The certifying center, in turn, confirms or refutes the ownership of the public key to the specified person who owns the corresponding private key.

The main components of PKI:

• The certifying center or Certification Center is an organization that performs, among other things, legal verification of data on participants in a network interaction (client or server). From a technical point of view, the Certification Center is a software and hardware complex that manages the lifecycle of certificates, but not their direct use. It is a trusted third party.
• A public key certificate (most often just ‘certificate’) consists of client or server data and public key signed with the electronic signature of the Certifying Center. The issuance of a public key certificate by a Certification Authority ensures that the person specified in the certificate also owns the private part of a single key pair.
• Registration Center (RC) is an intermediary of the Certification Center that acts on the basis of trust in the root Certification Center. The Root Certification Center trusts the data received by the Registration Center while verifying the information about the subject. After verifying the authenticity of the information, the Registration Center signs it with its own key and transmits the data it has received to the root Certification Center. The Root Certification Authority verifies the registration authority’s signature and, if successful, issues a certificate. One Registration Center can work with several Certification Centers (in other words, it can consist of several PKIs), just as one Certification Center can work with several Registration Centers. This component may not be present in the corporate infrastructure.
• Repository – a repository of valid certificates and a list of revoked certificates that are constantly updated. The list of revoked certificates (Certificate Revocation List, CRL) contains data on issued certificates whose paid period or validity period have elapsed, as well as certificates of resource owners that have been compromised or have not been authenticated. In the Federal Law of the Russian Federation No. 63 "On Electronic Signatures", this component is called the register of signature key certificates.
• A Certificate Archive is a repository of all certificates ever issued (including expired certificates) within the current PKI. The certificate archive is used for security incident investigations, which include verifying all data that has ever been signed.
• The Request Center is the personal account of the Certification Center’s clients, where end users can request a new certificate or revoke an existing one. It is implemented most often in the form of a web interface for the registration center.
• End users are clients, applications, or systems that own a certificate and use the public key management infrastructure.

3. How the Browser Works with SSL Certificates

3.1 What Happens in the Browser When the Certificate Is Checked?

Regardless of any extensions, browsers should always check a certificate’s basic information, such as the signature or the publisher. Steps for verifying Certificate Information:

1.   Checking the integrity of the certificate. This is done with the cryptographic Verify operation with a public key. If the signature is invalid, then the certificate is considered fake: it has been modified after it was issued by a third party, so it is rejected.

2.   Verifying the validity of the certificate. This is done with the cryptographic Decrypt operation, and by reading the accompanying information. The certificate is considered valid as long as the period for which the client has paid has not elapsed, or the expiration date has not passed. The expiration date of the certificate is the length of time for which the owner’s identity is validated by the Certifying Center that issued the certificate. Browsers reject any certificates with an expiration date that has expired before or started after the date and time of verification.

3.   Checking the certificate revocation status. This is done with the cryptographic Decrypt operation, and loading and reconciliation with CRL. A number of circumstances, for example, law enforcement agencies’ appeals, the identification of a change in the source information or confirmation of the fact that the server's private key has been compromised, can make the certificate invalid before its expiration date. To do this, the certificate is added to the CRL on the side of the Certifying Center.

Certification authorities periodically release a new version of the signed CRL, and it is distributed in public repositories. Browsers access the latest version of the CRL when verifying the certificate. The main drawback of this approach is that it limits verification to the CRL issuance period. The browser will be informed of the revocation only after it receives the current CRL. Depending on the policy of the signing Certification Authority, the CRL update period can be calculated in weeks.

When working with TLSv2 and TLSv3, the browser can use the OCSP Network Certificate Status detection protocol described in RFC 6960. OCSP allows the browser to request the revocation status of a particular certificate online (the reply operation). If the OCSP is configured correctly, the verification of certificates in the CRL is much faster and avoids the use of actually revoked certificates until the next CRL update. There is an OCSP Stapling technology that allows you to include a copy of the response to the certificate status request from the Certifying Center in the headers of the HTTP responses of the web server, which in turn increases the performance and speed of data exchange.

4.   Verification of the certificate publisher by the certificate chain.

Certificates are usually associated with several Certification Authorities: the root authority, which is the owner of the public key for signing certificates, and a number of intermediary ones, which refer to previous owners of the public key all the way up to the root one.

Browsers check the certificates of each Certifying Authority for being in the chain of trust with the root at the head. For added security, most PKI implementations also verify that the public key of the Certifying Authority matches the key with which the current certificate was signed. Thus, self-signed certificates are determined, because they have the same publisher only on the server where they were issued, or were added to the list of root certificates.

The X.509 v3 format allows you to determine which chain certificates should be checked. These restrictions rarely affect the average Internet user, although they are quite common in corporate systems at the development and debugging stage.

5.   Checking the domain name restriction

The certification authority may restrict the validity of the certificate on a server with a specific domain name or a list of the organization's child domains. Domain name restrictions are often used for intermediate Certification Authority certificates purchased from a publicly trusted Certification Authority to exclude the possibility of issuing valid certificates for third-party domains.

6.   Checking the certificate issuance policy

The Certificate Issuance Policy is a legal document published by the Certification Authority, which describes in detail the procedures for issuing and managing certificates. Certification authorities can issue a certificate in accordance with one or more policies, links to which are added to the information of the issued certificate so that the verifying parties can validate these policies before deciding whether to trust this certificate. For example, restrictions may be imposed on the region or time frame (for the period of technological maintenance of the Certification Center software).

7.   Checking the length of the certificate chain

The X.509 v3 format allows publishers to define the maximum number of intermediate certification authorities that can support a certificate. This restriction was introduced after the possibility of forgery of a valid certificate was demonstrated in 2009 by including a self-signed certificate in a very long chain.

8.   Verifying the public key assignment

The browser checks the purpose of the public key contained in the certificate encryption, signatures, certificate signature and so on. Browsers reject certificates, for example, if a server certificate is found with a key intended only for CRL signing.

9.   Checking the rest of the chain certificates

The browser checks each certificate of the chain. If the verification data was completed without errors, then the entire operation is considered valid. If any errors occur, the chain is marked as invalid and a secure connection is not established.

3.2 How to View Certificate Information and Check that Everything Is Working Correctly

The security certificate can be checked directly in the browser. All modern browsers display certificate information visibly in the address bar. If a secure connection with a web resource is established, a lock icon is displayed on the left of the browser address bar. In case of an error, the crossed-out word "HTTPS" or an open lock icon will be displayed. Depending on the type of browser and its version, the type of icons and behavior when working with SSL certificates may differ. Below are examples of images for different versions of modern browsers:

Google Chrome

Mozilla Firefox

Opera

Microsoft Edge

Chrome for Android

Safari for iOS

To view the details of the certificate, click on the lock icon and in the subsequent menu, click on the option that outlines the security details. Information about the certificate will appear after clicking on the appropriate button or information link.

Google Chrome

Mozilla Firefox

Microsoft Edge

Chrome for Android

3.3 A Message that the Browser Does Not Trust the Certificate

Most browsers display a security warning. These warnings inform you that the certificate has not been verified by a trusted certificate authority.

There are a number of reasons why an SSL certificate may be considered invalid in the browser. The most common reasons are:

• Errors in the certificate chain installation process, the intermediate certificate is missing;
• The SSL certificate has expired;
• The SSL certificate is valid only for the primary domain, not for subdomains;
• A self-signed SSL certificate has been used, or the root certificate of the Certification Authority has not been added to the trusted list on the current device.

4. Certification Centers

4.1 More Details about the Certification Centers

As mentioned above, the main task of the Certification Center is to confirm the authenticity of encryption keys using electronic signature certificates. The overarching operating principle can be described by the phrase "users do not trust each other, but everyone trusts the Certifying Center."

Any HTTPS interaction is based on the fact that one participant has a certificate signed by the Certification Authority, and the other attempts to verify the authenticity of this certificate. Verification will be successful if both participants trust the same Certification Authority. To solve this problem, the Certification Center’s certificates are preinstalled in operating systems and browsers. If the Certification Authority itself has issued a certificate, it is called a root certificate. A certificate issued by a partner of the Certification Authority with which it has a trust relationship is called an intermediate certificate. As a result, a tree of certificates is formed with a chain of trust between them.

By installing the certificate of the Certifying Center in the system, you can trust the certificates that have been signed with it. A certificate (particularly for HTTPS) that is issued but not signed by a root or intermediate Certification authority is called a self-signed certificate and is considered untrusted on all devices where this certificate is not added to the root/intermediate lists.

According to the distribution level of certificates, the Certification Center can be international, regional, and corporate. The public key management infrastructure’s activities are carried out in accordance with the regulations of the appropriate level: i.e. public directives recorded by the international community of Internet users, the legislation of the region, or the relevant provisions of the organization.

The main functions of the certification center are:

• verifying the identity of future certificate users;
• issuing certificates to users;
• revoking certificates;
• maintaining and publishing lists of revoked certificates (Certificate Revocation List/CRL), which are used by public key infrastructure clients when they decide whether to trust a certificate.

Additional functions of the certification center are:

• Generating key pairs, one of which will be included in the certificate.
• Upon request, when resolving conflicts, the UC can verify the authenticity of the electronic signature of the owner of the certificate issued by this UC.

Browsers and operating systems of devices fix the trust of the Certifying Center by accepting the root certificate into their storage – a special database of root certificates of Certifying centers. The storage is placed on the user's device after installing the OS or browser. For example, Windows maintains its root certificate store in operating systems, Apple has a so-called trust store, Mozilla (for its Firefox browser) creates a separate certificate store. Many mobile operators also have their own storage. Regional and corporate should be added either at the stage of software certification in the country, or by contacting the technical support of the organization.

Regional representatives of the world Certification Centers have the authority to make legal requests for the activities of organizations related to the publication of web resources. For corporate Certification Centers, this is not necessary, since they usually have access to the internal information of the organization. For security purposes, Certification Authorities should not issue digital certificates directly from the root certificate transmitted to operators, but only through one or more Intermediate Certificate Authority, ICA. These intermediate Certification Authorities are required to comply with security recommendations in order to minimize the vulnerability of the root Certification authority to hacker attacks, but there are exceptions. For example, GlobalSign is one of the few certification authorities that have always (since 1996) used ICA.

Certificates come in different formats and support not only SSL, but also the authentication of people and devices, as well as certifying the authenticity of code and documents. Within the Russian legislative framework, such activities must be licensed by the FSB, since they are related to cryptographic operations.

The universal algorithm for obtaining a certificate from the Certification Center:

1.   Private key generation
2.   Creation of a certificate signing request (CSR request)
3.   Procurement of a certificate signed by the Certificate Authority’s root certificate after passing the checks
4.   Configuration of the web server for your resource

Since browsers have a copy of the international Certification Authority’s root certificate, as well as a number of intermediate certificates from the chain of trust, the browser can check whether a certificate was signed by a trusted certification authority. When users or an organization create a self-signed certificate, the browser does not trust it as it knows nothing about the organization, so the root certificate of the organization must be manually added to all controlled devices. These certificates will become trusted after this.

4.2 What Are Root Certificates?

A root certificate is a file that contains service information about the Certification Authority. Special software or a library that verifies, encrypts and decrypts information is called a crypto provider (a provider of cryptographic functions). The cryptographer gets access to the encrypted information, thereby confirming the authenticity of the personal electronic signature.

A chain of trust for the certificates is then built based on the certifying center’s root certificate. Any electronic signature issued by the Certifying Center only works if there is a root certificate.

The root certificate stores information with the dates of its validity. The cryptographic provider can also get access to the organization's registry through the root certificate.

4.3 What Is a Certificate Chain?

Historically and technologically, certain Certification Centers are widely recognized among SSL users, and as a result, it was agreed that the certificates they issued would be considered root certificates, and they would always be trusted. Regional Certifying certificates, in turn, can be confirmed by the root Certifying center. In turn, they can confirm other certificates, forming a chain of trust to certificates. The Certifying Center acts as a guarantor-certifier which issues an SSL certificate at the request of the owner of a web resource.

The certificate and the web resource to which it is issued are certified by an electronic digital signature (EDS). This signature indicates who the owner of the certificate is and records its contents, that is, it allows you to check whether it has been changed by someone after it was issued and signed.

The list of certificates of root Certifying centers and their public keys is initially placed in the operating system’s software storage on the users' workstation, in the browser, and in other applications that use SSL.

If the chain of sequentially signed certificates ends with the root certificate, all certificates included in this chain are considered confirmed.

Root certificates located on the user's workstation are stored in a container protected by the operating system from accidental access. However, the user can add new root certificates themselves, and this is a source of potential security problems.

By carrying out certain actions and accessing an attacked workstation, an attacker can include their own certificate among the root certificates and use it to decrypt the data that is received.

The Root Certification Center can be formed by the government of a particular country or the leaders of an organization. In these cases, root Certification Centers will not operate everywhere, but they can nonetheless be used quite successfully in a specific country or within a specific enterprise.

At present, the list of root certification authorities on the user's computer can be automatically changed when updating the operating system, software products, or manually by the system administrator.

Certification centers can issue a variety of SSL certificates linked by what is known as a tree structure. The root certificate is the root of the tree, with the secret key with which other certificates are signed. All intermediate certificates that are at a lower level inherit the degree of trust that the root certificate has. SSL certificates located further down the structure receive trust in the same way from the Certifying Centers located higher up the chain. Using the example of the Comodo Certification Center, the structure of SSL certificates can explained as follows:

1.   The root certificate of the Comodo Certification Authority: AddTrustExternalCARoot

2.   Intermediate Certificates: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo High-Assurance Secure Server CA

3.   SSL certificates for individual domains

5. General Information about Certificate Types

5.1 Paid Trusted Certificates

The purchase of trusted certificates, except in some cases, is a paid service.

5.1.1 Where and How to Buy

In most cases in Russia, web resource hosting companies or partner organizations of international Certification centers provide SSL certificate services. It is possible to purchase certificates directly from Certification Centers, but such certificates are usually more expensive than from partners who purchase them in bulk.

The procedure for purchasing an SSL certificate is no different from purchasing other internet services. It entails:

1.   Selecting a supplier and going to the SSL certificates order page.

2.   Selecting the appropriate SSL certificate and clicking the purchase button.

3.   Entering the name of your domain and selecting the protection option — for one domain or Wildcard certificate for a group of subdomains.

4.   Paying for the service in whichever way is most convenient.

5.   Continue configuring the service in accordance with the following parameters:

a.   The number of domains that the certificate protects (i.e. one or more).
b.   Subdomain support.
c.   The speed of release. Certificates with domain-only validation are issued the quickest, while certificates with EV validation are issued the slowest.
d.   Most Certifiers offer unlimited certificate reissues. This is required if there are mistakes in the organization data.
e.   Warranty – for some certificates there is a $10,000 warranty. This is a guarantee not for the certificate buyer, but rather for the visitor of a site that installs a certificate. If a site visitor with such a certificate suffers from fraud and loses money, the Certification Center undertakes to compensate the stolen funds up to the amount specified in the guarantee. In practice, such cases are extremely rare.
f.   Free trial period – Symantec Secure Site, Geotrust Rapidssl, Comodo Positive SSL, Thawte SSL Web Server certificates have paid certificates. There are also free certificates.
g.   Refund – almost all certificates have a 30-day refund policy, although there are certificates without this.

5.1.2 Approximate Cost

SSL certificates can be separated into different groups based on their properties.

1.   Regular SSL certificates. These are issued instantly and confirm only one domain name. Cost: from $20 per year

2.   SGC certificates. These support customers with increasing the level of encryption. Server Gated Cryptography technology allows you to forcibly increase the encryption level to 128 bits in older browsers that supported only 40 or 56 bit encryption. Cryptography is used to solve this problem, but it cannot cope with the other vulnerabilities present in unsecure browsers, so there are a number of root Certification centers that do not support this technology. Cost: from $300 per year.

3.   Wildcard certificates. They provide encryption of all subdomains of the same domain by mask. For example, there is a domain domain.com; if the same certificate must be installed on support.domain.com , forum.domain.com and billing.domain.com , customers can issue a certificate for *.domain.com . Depending on the number of subdomains that need the certificate, it may be more cost-effective to purchase several ordinary SSL certificates individually. Examples of wildcard certificates: Comodo PositiveSSL Multi-Domain Wildcard and Comodo Multi-Domain Wildcard SSL. Cost: from $180 per year.

4.   SAN Certificates Subject Alternative Name technology allows customers to use one certificate for several different domains hosted on the same server. Such certificates are also referred to as UCC (Unified Communication Certificate), MDC (Multi-domain certificate) or EC (Exchange Certificate). Generally, one SAN certificate includes up to 5 domains, but this number can be increased for an additional fee. Cost: from $395 per year.

5.   Certificates with IDN support Certificates with national domain support (International Domain Name, such as *.RU, *.CN, *.UK). Not all certificates can support IDN. This must be clarified with the Certification Center. Certificates supporting IDN include:

• Thawte SSL123 Certificate;
• Thawte SSL Web Server;
• Symantec Secure Site;
• Thawte SGC SuperCerts;
• Thawte SSL Web Server Wildcard;
• Thawte SSL Web Server with EV;
• Symantec Secure Site Pro;
• Symantec Secure Site with EV;
• Symantec Secure Site Pro with EV.

As is mentioned above, partners of Certification Centers can provide significant discounts on prices — starting at $10 — or offer service packages.

5.1.3. Certificate Validation

Certificates are divided into the following levels of validation:

1.   DV

Domain Validation, or certificates with domain validation. The certification authority verifies that the client who requests the certificate controls the domain that needs the certificate. A network service for verifying the ownership of WHOIS web resources is used to do this. This type of certificate is the cheapest and most popular, but it is not completely secure, since it contains only information about the registered domain name in the CN field (CommonName is the common domain name of a web resource).

2.   OV

Organization Validation, or certificates with organization verification. The certification center verifies the affiliation of a commercial, non-profit or government organization to the client, who must provide legal information when purchasing. This type of certificate is seen as more reliable, since it meets the RFC standards and also confirms the registration data of the owner company in the following fields:

• O (Organization – name of the organization);
• OU (Organizational Unit – name of the organization's division);
• L (Locality – name of the locality of the organization’s legal address);
• S (State or Province Name – name of the territorial and administrative unit of the organization’s legal address);
• C (Country Name – the name of the organization's country).

The certification center can contact the company directly to confirm this information. The certificate contains information about the person that confirmed it, but not data about the owner. An OV certificate for a private person is called IV (individual validation/ individual verification) and verifies the identity of the person requesting the certificate.

3.   EV

Extended validation, or a certificate with extended validation. The Certification Center verifies the same data as the OV, but in accordance with stricter standards set by CA/Browser Forum. CA/Browser Forum (Certification Authority Browser Forum)is a voluntary consortium of certification authorities, developers of Internet browsers and software for secure email, operating systems, and other applications with PKI support. The Consortium publishes industry recommendations governing the issuing and management of certificates. This type of certificate is considered the most reliable. Previously, when using these certificates in a browser, the color of the address bar changed and the name of the organization was displayed. It is widely used by web resources that conduct financial transactions and require a high level of confidentiality. However, many sites prefer to redirect users to make payments to external resources confirmed by certificates with extended verification, while using OV certificates which are secure enough to protect the rest of the user data.

5.1.4. The Setup Process (General Information, What Is CSR?)

To initiate the certificate issuing process, a CSR request must be made. Technically, a CSR request is a file that contains a small fragment of encrypted data about the domain and the company to which the certificate is issued. The public key is also stored in this file.

The CSR generation procedure depends entirely on the software used on your server, and is most often performed using the settings in the administrative panel of your hosting. If your hosting does not provide this, then you can use online services to generate a CSR request, or alternatively you can turn to specialized software, such as OpenSSL, GnuTLS, Network Security Services, etc. After generating the CSR, the private key will also be generated.

To successfully generate a CSR, you need to enter data about the organization that has requested the certificate. The information must be entered in the Latin alphabet. The following parameters are sufficient:

• Country Name — the country of registration of the organization in two-letter format. For the Russian Federation — RU;
• State or Province Name — region, region of registration of the organization. For Moscow — Moscow;
• Locality Name — the city where the organization is registered. For Moscow — Moscow;
• Organization Name — the name of the organization. For individuals, "Private Person" is indicated;
• Common Name — the domain name of those who have requested the certificate;
• Email Address — the administrator’s email address. Acceptable values:
  •   admin@domain_name;
  •   administrator@domain_name;
  •   hostmaster@domain_name;
  •   postmaster@domain_name;
  •   webmaster@domain_name.

5.2. Self-Signed Certificates

Self–signed certificates are SSL certificates created by the service developers themselves. A pair of keys for them is generated through specialized software, for example, OpenSSL. Such a communication channel may well be used for internal purposes, i.e. between devices within your network or applications at the development stage.

5.3. Let’s Encrypt

Let's Encrypt is an Authentication Center that provides free X.509 cryptographic certificates for encrypting HTTPS data transmitted over the Internet and other protocols used by servers on the Internet. The process of issuing certificates is fully automated. The service is provided by the public organization Internet Security Research Group (ISRG).

The Let's Encrypt project was started to translate most of the Internet sites to HTTPS. Unlike commercial Certification centers, this project does not require payment, reconfiguration of web servers, use of e-mail, or the processing of expired certificates. This simplifies the installation and configuration of TLS encryption. For example, on a typical Linux-based web server, you need to run two commands that will configure HTTPS encryption, receive and install a certificate in about 20-30 seconds.

Let's Encrypt root certificates are installed as trusted by major software vendors, including Microsoft, Google, Apple, Mozilla, Oracle and Blackberry.

The Let's Encrypt Certification Authority issues DV certificates with a validity period of 90 days. It has no plans to start issuing OV or EV Certificates, although it began providing support for Wildcard certificates some time ago.

The key to the root certificate of the RSA standard has been stored in the HSM hardware storage since 2015 and is not connected to the network. This root certificate is signed by two intermediate root certificates, which were also signed by the IdenTrust certification authority. One of the intermediate certificates is used to issue sites’ final certificates, while the second is kept as a backup in storage that is not connected to the Internet, in case the first certificate is compromised. Since the root certificate of the IdenTrust center is preinstalled in most operating systems and browsers as a trusted root certificate, the certificates issued by the Let's Encrypt project are verified and accepted by clients — despite the absence of the ISRG root certificate in the trusted list.

The Automated Certificate Management Environment (ACME) authentication protocol is used to automatically issue a certificate to the destination site. In this protocol, a series of requests are made to the web server that seeks a signature for the certificate to confirm the ownership of the domain (DV). To receive requests, the ACME client configures a special TLS server, which is polled by the ACME server using Server Name Indication (Domain Validation using Server Name Indication, DVSNI).

Validation is carried out repeatedly, using different network paths. DNS records are pulled from a variety of geographically distributed locations to prevent DNS spoofing attacks. This is when domain name cache data is changed by an attacker in order to return a false IP address and redirect the intermediary to the attacker's resource (or any other resource on the network)1.

6. Paid Trusted Certificates

6.1 Usage on Windows Server and IIS

6.1.1 What Are the Formats of the Private Key?

These are today’s private key formats:

1.   PEM format

This format is most often used by Certification Authorities. PEM certificates most often have extensions *.pem, *.crt, *.cer or *.key (for private keys) and others. For example, the package file SSL.com The CA available in the download table in the order of the certificate has the extension *.ca-bundle. The contents of the files are encrypted using Base64 and contain the strings "--BEGIN CERTIFICATE--" and "--END CERTIFICATE--".

This certificate format is common in Linux OS. Multiple PEM certificates and even a private key can be included in one file, one under the other. But most servers, such as Apache, expect the certificate and private key to be in different files.

2.   PKCS#7/P7B format

PKCS#7 or P7B format certificates are usually saved in Base64 ACVII format and have the extension *.p7b or *.p7c. The P7B certificate contains the strings "--BEGIN PKCS7--" and "--END PKCS7--". This format contains only the certificate and certificate chain, but not the private key. Several commonly-used platforms support this format, including Microsoft Windows and Java Tomcat.

3.   PKCS#12/PFX format

PKCS#12 or PFX format is a binary format for saving a certificate, any intermediate certificates, and a private key in one encrypted file. PFX files are usually saved with the extension *.pfx or *.p12. As a rule, this format is used on Windows certificates to export/import the certificate and private key 2.

6.1.2 How to Generate a CSR Request

To generate a CSR request in IIS 10, perform the following operations:

1.   Run IIS from the iis.msc command line or from the visual interface.

2.   Select your server from the Connections list and click the Server Certificates button.

3.   On the Server Certificates page, click the Create Certificate Request link in the Actions block.

4.   In the Request Certificate window of the wizard, fill in the CSR fields and click Next.

5.   In the Cryptographic Service Provider Properties window of the wizard, select the required cryptographic provider, depending on the desired algorithm and the key length, and then click Next.

6.   In the File Name window of the wizard, specify the path to the CSR being created, and then click Finish.

To send the finished CSR to the Certification Center, open the file in a text editor and copy the contents to the web form of the certificate provider.

6.1.3 How to Create a Private Key

As a result of creating the CSR, the private key will be created automatically by IIS. Viewing is available on the Certificates console snap-in in the Personal or Web Hosting points of the certificate tree.

The snap-in can be hidden in the console. To add it, run the mmc command in Start menu > Run and in the window that appears, add the Certificates snap-in to the list available on the local machine:

6.1.4 How to Export It

To export a private key for backup purposes or to configure a new server, follow these steps:

1.   Find the certificate in the Certificates snap-in of the management console, and right-click on it. In the context menu that appears, click on the menu item All Tasks > Export;

2.   In the Welcome to the Certificate Export wizard window of the Certificate Export Wizard, click Next and then in the Export Private Key window, set the switch to Yes, export the private key, and then click Next;

3.   In the Export File Format window of the wizard, select the type item Personal Information Exchange – PKCS #12 (.PFX) and select the checkbox Include all certificates in the certification path if possible. Then click Next. Be aware that if the Delete the private key if the export is successful checkbox is checked, the private key created on the current server will be deleted after export;

4.   In the Security wizard window, fill the Password checkbox and enter the password twice to protect the private key. It will be required for the subsequent import. Additionally, it is recommended that Active Directory users or groups that have the ability to use a private key are restricted. To do this, fill the Group or User Name checkbox and select Required Groups or Users, then click Next;

5.   In the File to Export window of the wizard, specify the path to the exported file with the private key and its name. To do this, enter it manually or use the system file search dialog box, then click Next;

6.   In the File to Export window of the wizard, specify the path to the exported file with the private key and its name. To do this, enter it manually or use the system file search dialog box, and then click Next. In the next window Completing the Certificate Export Wizard, a list of the installed settings will appear. Click Finish. The exported file will appear in the specified directory.

6.1.5 How to Configure SSL on IIS

To configure SSL in IIS, follow these steps:

1.   Run IIS from the iis.msc command line or from the visual interface.

2.   Select your server from the Connections list and click on the Bindings... link in the Actions block.

3.   In the Site Bindings window, click Add.

4.   In the Add Site Bindings window, fill in the following fields and click OK.

• IP address – select the IP addresses of the servers with which the certificate will be associated from the drop-down list or click the All Unassigned button to associate the certificate with all servers.
• Port – leave the value 443. This is a standard SSL port.
• SSL certificate – select the required SSL certificate from the drop-down list.

The setup is finished, you can check the operation of the web service. If the private key is missing, then import it in the Certificates snap-in of the Management console. To do this, select the desired resource and right-click on it. Then, in the context menu that appears, click on the menu item All Tasks > Import, and follow the instructions of the wizard.

6.2 Usage on Linux

6.2.1 How to Create a Private Key

The private key that has been created can be obtained in the interface of the SSL certificate provider after sending the CSR or using specialized software, such as OpenSSL, for example.

Below is a fragment of private key generation in the web interface of the SSL certificate provider.

If the private key was created in the web interface, then the export is carried out by clicking the button there. After clicking on the button, the browser starts downloading the archive with the key file in the desired format.

To create a private RSA key using OpenSSL, one command is enough:

openssl genrsa -out rsaprivkey.pem 2048

This command generates the PEM private key and stores it in the rsaprivkey.pem file. In our example, a 2048-bit key is created, which is suitable for almost all situations.

To create a DSA key, you need to perform two steps:

openssl dsaparam -out dsaparam.pem 2048
openssl gendsa -out dsaprivkey.pem dsaparam.pem

The first step creates a DSA parameters file (dsaparam.pem), which in this case contains instructions for OpenSSL to create a 2048-bit key in step 2. The dsaparam.pem file is not a key, so it can be deleted after the public and private keys are created. In the second step, a private key is generated (dsaprivkey.pem file), which must be kept secret.

To create a file in the PKCS#12 format used in Windows OS, use the following command:

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

Where:

• pkcs12 – private key format;
• export – the operation of exporting the private key to the required format;
• out – the directory in the file system where the resulting file should be placed;
• inkey – private key file in PEM format;
• in – file of the certificate received from the Certifying Center;
• certfile is a copy of the root certificate and intermediate certificates in the chain. In the example above, they are missing.

6.2.2 How to Generate a CSR Request

To generate a CSR, fill in the suggested fields in the web form of the SSL certificate service provider. The figure above demonstrates an example of this. The set of minimum required fields is the same and is given in the section about CSR description, but some vendors can add their own or change the input method.

To generate CSR using OpenSSL, use the following command:

openssl req -new -key private.key -out domain_name.csr -sha256

Where:

• new – creating a new CSR request by direct input in the console. Without this option, the OpenSSL configuration file data will be used;
• key – the name of the private key required for generation. If the option is not specified, a new private key will be created according to the default algorithm;
• out – the path to the CSR file being created;
• sha256 is an encryption algorithm.

After executing the command, a request to fill in the required fields will appear in the console.

Then send the resulting CSR to the Certifying Center. In response, a personal certificate must be returned.

6.2.3 How to Configure SSL for Apache

Follow these steps to configure SSL in Apache:

1.   Add the personal certificate issued by the Certification Authority, the private key, and the root certificate to the /etc/ssl/ directory — along with the rest of the certificates in the chain.

2.   Open the Apache configuration file with any text editor: vim, for example. Depending on the server OS, the file may be located in one of the following locations:

• for CentOS: /etc/httpd/conf/httpd.conf;
• for Debian/Ubuntu: /etc/apache2/apache2.conf;

3.   If you are installing an SSL certificate on an OpenServer, use the path to its root folder. At the end of the file, create a copy of the "VirtualHost" block. Specify port 443 for the block and add the following lines inside:

SSLEngine on
SSLCertificateFile /etc/ssl/domain_name.crt
SSLCertificateKeyFile /etc/ssl/private.key
SSLCertificateChainFile /etc/ssl/chain.crt

4.   Check the Apache configuration before restarting with the command: apachectl configtest, then restart Apache.

6.2.4 How to configure SSL for Nginx

Follow these steps to configure SSL in Nginx:

1.   Open a text editor and add the contents of the personal certificate issued by the Certification Authority, and the root certificate — along with the rest of the certificates in the chain. The resulting file should look like this:

----BEGIN CERTIFICATE-----
#Your certificate#
----END CERTIFICATE-----
----BEGIN CERTIFICATE-----
#Intermediate certificate#
----END CERTIFICATE-----
----BEGIN CERTIFICATE-----
#Root certificate#
----END CERTIFICATE-----

2.   Save the resulting file with the *.crt extension to the /etc/ssl/ directory. Please note: the second certificate should come directly after the first, without any empty lines.

3.   Save the your_domain file.key with the certificate's private key in the /etc/ssl directory.

4.   Open the Nginx configuration file and edit the virtual host of your site that you want to protect with a certificate. Perform the minimum setup for the job by adding the following lines to the file:

server {
listen 443 ssl;
server_name your_domain.com;
ssl_certificate /etc/ssl/your_domain.crt;
ssl_certificate_key /etc/ssl/your_domain.key;
}

Where:

• your_domain.com — the domain name of the site;
• /etc/ssl/your_domain.crt — the path to the file created with three certificates;
• /etc/ssl/your_domain.key — the path to the file with the private key.

The names of files and directories can be arbitrary.

Additionally, you can configure the operation of the site over HTTP, the type of server cache, the cache update timeout, and the operating time of a single keepalive connection. You can also configure the supported protocols and their level of priority (server set or client set), as well as OCSP responses for certificate validation. Details are given in the Nginx user manual.

5.   For the changes to take effect, restart the Nginx server with the following command:

sudo /etc/init.d/nginx restart

7. Self-Signed Certificates

7.1 Usage on Windows Server and IIS

7.1.1 How to Create a Private Key

You can create a private key with IIS by creating a CSR and then actioning the above instructions.

7.1.2 How to Create a Self-Signed Root Certificate

To generate a self-signed root certificate in IIS 10, perform the following operations:

1.   Run IIS from the iis.msc command line or from the visual interface.

2.   Select your server from the Connections list and click on the Server Certificates button.

3.   On the Server Certificates page, click the Create Domain Certificate link in the Actions block.

4.   In the Distinguished Name Properties window of the Create Certificate wizard, fill in the Common Name field (the server name specified in the browser), the remaining fields that were filled when creating the CSR, and click Next.

5.   In the Online Certification Authority window of the wizard, specify in the Specify Online Certification Authority field the repository where you want to place the root certificate. In the Friendly Name field, specify the name of the certificate, and then click Finish.

7.1.3 How to Create an SSL Certificate Signed by the Root

To generate a self-signed SSL certificate in IIS 10, perform the following operations:

1.   Run IIS from the iis.msc command line or from the visual interface.

2.   Select your server from the Connections list and click on the Server Certificates button.

3.   On the Server Certificates page, click the Create Self-Signed Certificate link in the Actions block.

4.   In the ‘Create Self-Signed Certificate’ window in the ‘Friendly Name’ field, specify the name of the certificate in the ‘Select a Certificate Store for the New Certificate’ field. Then, select the repository in which the self-signed certificate will be stored, and click OK.

7.1.4 How to Configure IIS for a Self-Signed Certificate

IIS configuration for Configuring IIS for a self-signed certificate requires the same process as a certificate issued by a Certification Authority.

7.2 Usage on Linux

7.2.1 How to Create a Private Key

Creating a private key using the genrsa command and other similar ones in OpenSSL is described above.

7.2.2. How to Create a Self-Signed Root Certificate

To generate a self-signed root certificate in OpenSSL, run the following command:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Where:

• key – a private key created earlier;
• out – root certificate file;
• days – the number of days the certificate is valid, starting from the current day.

7.2.3. How to Create an SSL Certificate Signed by the Root

To generate a self-signed SSL certificate in OpenSSL, follow these steps:

1.   Create a CSR according to the instructions above.

2.   Issue a self-signed certificate:

openssl x509 -req -in org.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out org.crt -days 365 -sha256

Where:

• req – create a signature request;
• in – file of the CSR request;
• CA file of the root certificate;
• CAkey – private key of the root certificate;
• out – output CRT file;
• days – the number of days of the action.

7.2.4. How to Configure Apache for a Self-Signed Certificate

Apache configuration for a self-signed certificate is performed in the same way as for a certificate issued by a Certification Authority.

7.2.5. How to Configure Nginx for a Self-Signed Certificate

Nginx configuration for a self-signed certificate requires the same process as a certificate issued by a Certification Authority.

7.3 How to Make Self-Signed Certificates Trusted

7.3.1 On Windows

To make a self-signed certificate trusted, follow these steps:

1.   Find the repository of trusted certificates in the Certificates snap-in of the management console. Right-click on it, and then in the Context Menu that appears, click on the menu item All Tasks > Import;

2.   In the Welcome to the Certificate Import wizard window of the Certificate Import wizard, click Next. Then, in the File to Import window, specify the path to the imported file with the self-signed certificate. To do this, either enter it manually or use the system file search dialog box. Afterwards, click Next.

3.   In the Private Key Protection window of the wizard, enter the password specified when creating the self-signed certificate. Set the checkboxes Mark this key as exportable to allow further export of the certificate for backup purposes, and Include all extended properties, then click Next. Further export will only work if the private key is available.

4.   In the Certificate Store window of the wizard, turn on Place all certificates in the following store, select the Trusted Root Certification Authorities repository, and then click Next. In the next window Completing the Certificate Import Wizard, you will see a list of the installed settings. Click Finish. The imported file will appear in the specified repository.

7.3.2 On macOS

To add a self-signed certificate to trusted certificates, follow these steps:

1.   Open the Keychain Access application by clicking on the icon below and go to the All Items menu item.

2.   Use Finder to find the self-signed certificate file (*.pem, *.p12 or other).

3.   Drag the file to the left side of the Keychain Access window.

4.   Go to the Certificates menu item, find the self-signed certificate that has been added and double-click on it.

5.   Click on the Trust button in the drop-down menu and set the When using this certificate field from System Defaults to Always Trust.

7.3.3 On Linux

To add a self-signed certificate to trusted ones in Linux OS (Ubuntu, Debian), follow these steps:

1.   Copy the root self-signed certificate file to the /usr/local/share/ca-certificates/ directory. To do this, run the command sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt, where foo.crt is the personal certificate file.

2.   Run the sudo update-ca-certificates command.

To add a self-signed certificate to trusted certificates in Linux OS (CentOS 6), follow these steps:

1.   Install the root certificates using the command: yum install ca-certificates.

2.   Enable the dynamic configuration mode of root certificates: update-ca-trust force-enable.

3.   Add the certificate file to the directory /etc/pki/ca-trust/source/anchors/: cp foo.crt /etc/pki/ca-trust/source/anchors/.

4.   Run the command: update-ca-trust extract.

7.3.4 On iOS

To add a self-signed certificate to trusted certificates, follow these steps:

1.   Install any web server and place the certificate file in the root of the application directory.

2.   Go to the URL of the web server, after which the file will be downloaded to the profile of the current user.

3.   Open the Profiles menu and click Install.

4.   Go to Settings > General > About-> Certificate Trust Settings and set the switch for the certificate to Enabled.

7.3.5 On Android

To make a self-signed certificate trusted, follow these steps:

1.   Download the file to the device.

2.   Go to Settings > Security > Credential Storage and tap Install from Device Storage.

3.   Find the *.crt that has been downloaded and enter its name in the Certificate Name field. After it has been imported, the certificate will be displayed in Settings > Security > Credential Storage > Trusted Credentials > User.

7.3.6 How to Make a Root Certificate Trusted in Windows AD Group Policies

To make a root certificate trusted in Windows Active Directory Group Policies, follow these steps:

1.   Run the Group management snap-in from the gpmc.msc command line.

2.   Select the desired domain, right-click on it, and select Create a GPO in this domain and link it here.

3.   Specify the name of the group policy in the window that appears and click OK.

4.   Right-click on the created group policy and click Edit.... On the next screen, go to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update. Select Allow signed content from intranet Microsoft update service location and click Edit Policy Settings.

5.   Set the switch to Enabled and click OK.

6.   Go to Computer Configuration>Windows Settings >Security Settings>Public Key Policies and trust the required certificate in accordance with the instructions above.

7.   Repeat step 4 and close the Group Policy Editor. The policy will be applied shortly. To apply it immediately, run gpupdate /force on the command line.

8. Let’s Encrypt

8.1 Usage on Windows Server and IIS

8.1.1 How to Issue a Certificate

To install the Let's Encrypt certificate, an ACME client must be installed on the server. The following implementations are common for Windows:

• The Windows ACME Simple Utility (WACS) is a command–line utility for interactively issuing a certificate and binding it to a specific site on your IIS web server;
• The ACMESharp Powershell module is a Powershell library. It has many commands for interacting with Let's Encrypt servers via the ACME API;
• Certify is a graphical SSL certificate manager for Windows that allows you to interactively manage certificates via the ACME API.

To issue a Let's Encrypt certificate using WACS, follow these steps:

1.   Download the latest release of the WACS client from the project page on GitHub https://github.com/PKISharp/win-acme/releases and unpack it onto a directory on the server.

2.   Open a command prompt and run the client wacs.exe from the specified location.

3.   Press the N key. This will create a certificate for IIS.

4.   Select the certificate type: DV for one domain, DV for all domains in IIS (SAN), domains corresponding to Wildcard, or a manual list of domains in IIS.

5.   Depending on the choice, WACS.exe will display a list of sites running on the IIS server and will prompt you to select the desired site.

6.   After selecting the site, provide an email address to receive information about problems including site certificate updates (several addresses can be given if they are separated by commas).

7.   Agree to the terms of use by pressing the Y key, after which Windows ACME Simple will connect to Let's Encrypt servers and try to automatically generate a new SSL certificate for the site 3.

8.1.2 How to Configure IIS for Let's Encrypt Certificate

The WACS utility saves the certificate's private key (*.pem), the certificate itself, and a number of other files to the directory C:\Users\%username%\AppData\Roaming\letsencrypt-win-simple . It will then install the generated Let's Encrypt SSL certificate in the background and bind it to your IIS site.

For more details, see here https://www.win-acme.com/manual/getting-started

8.2 Usage on Linux

8.2.1 How to Issue a Certificate

To install the Let's Encrypt certificate, the ACME client must be installed on the server. For Linux, this is the Certbot utility.

To issue a Let's Encrypt certificate using Certbot, follow these steps:

1.   Install Certbot according to the instructions on the website https://certbot.eff.org / to the server.
2.   Execute the certificate issue command: certbot --nginx or certbot --apache. When launching for the first time, an email address for receiving information about problems site certificate updates and other alerts may be required.

Certbot will analyze the ServerName directive that corresponds to the domain name with the requested certificate in the web server’s configuration files. If you need to specify multiple domains or wildcard, use the command line key -d.

For more details, see: https://certbot.eff.org/instructions

8.2.2 How to Configure IIS for a Let's Encrypt Certificate

After executing the certbot command, the web server configuration will be updated automatically. The certbot client will display a successful completion message, and will also show the path to the directory where the certificates are stored.

9. Certificate Renewal for Linux and Windows

9.1 Paid Trusted

When extending the validity of the SSL/TLS certificate, creating a new CSR request is recommended. Generating a new request will create a new unique key pair (public/private) for the updated certificate.

The web interface of many SSL certificate providers allows you to renew the certificate manually or automatically. After renewing, the user will receive a new reissued certificate. This needs to be reconfigured again in accordance with the instructions above.

9.2 Self-Signed

Self-signed certificates are renewed by recreating and configuring the web server in accordance with the instructions described above.

9.3 Let’s Encrypt

9.3.1 On Windows

Windows ACME Simple creates a new rule in the Windows Task Scheduler (called win-acme-renew) to automatically renew the certificate. The task is started every day, and the certificate renewal itself is performed after 60 days. When extending, the scheduler runs the command:

C:\\<path to the WACS directory>\\wacs.exe --renew --baseuri "<https://acme-v02.api.letsencrypt.org >"

You can use the same command to manually update the certificate.

9.3.2 On Linux

To renew the certificate via certbot, you need to run the following command:

certbot Renew --force-Renewal

To specify a specific domain, use the -d parameter.

10. Testing

10.1 Services (SSL Checkers) that Allow You to Check SSL Tinctures on a Public Server

SSL verification is carried out using online services provided by Certification Centers, as well as third-party developers such as:

• https://ssltools.вебsecurity.symantec.com/checker/views/certCheck.jsp
• https://www.wormly.com/test_ssl
• http://www.digicert.com/help/
• http://www.sslshopper.com/ssl-checker.html
• https://sslcheck.globalsign.com/en_US
• https://www.ssllabs.com/ssltest/
• https://www.htbridge.com/ssl/
• https://sslanalyzer.comodoca.com/
• https://www.sslchecker.com/sslchecker

These services allow you to gain information about certificates, domains, organizations, cities, serial numbers, algorithms used, their parameters (such as key length) and details about the certificate chain.

10.2 Verification of the Entire Certificate Chain

The entire certificate chain is verified by SSL Shopper, Symantec SSL Toolbox and SSL Checker. The links are given above.

10.3 Checking on iOS (via a Special App)

To check certificates on iOS devices, install the SSL Checker app from the App Store. With this application, you can check the current status and validity of the SSL certificate of any server, including self-signed certificates. The application can detect changes in the certificate parameters and send notifications about it.

10.4 Checking on Android

To check certificates on Android devices, install the SSL Certificate Checker application from Google Play. Using this application, you can check the current status and attributes of the SSL certificate of any server, including the certificate chain.

Professionally coordinated operational communications allow warfare to be done while preventing escalation and/or emergency scenarios.

In order to ensure the highest possible security of soldier communications on missions, to prevent espionage, and perhaps even to win the war, it is necessary to use a large number of military information and communication technologies. They should not only protect and provide communications for operational activities but also enable an exchange between military personnel at the "internal" and "secret" communication levels.

Nowadays, the use of mobile devices for communication has become so commonplace that it has even spread to the industries of military and defence. This scenario uses programs for communication, which are often called instant messengers.

The armies of different countries are looking for secure ways to exchange messages. Some are turning to already available commercial solutions, while others are developing their messengers with the help of the open-source community. Let's take a look at what messengers are used in the armies of the world, and what are their features, advantages, and disadvantages.

USA

The US military leadership suggested the use of encrypted messengers Signal and Wickr in combat zones, including in the Middle East. Both were created by the open community and are available for free download.

Open Whisper Systems created Signal, which uses its proprietary Signal System encryption protocol, which is used by other messengers. Wickr has created a military-specific RAM version. End-to-end encryption is provided for chat messaging, audio and video conversations, secure screen sharing, and massive file transmission and storage.

The usage of Signal and Wickr, on the other hand, violates the US Freedom of Information Act, which states that email and text messages received in official government activities are public and must be made accessible upon request. At the same time, both messengers offer the ability to delete messages, which are not saved on senders' or receivers' devices or the company's servers.

France

European governments seeking digital sovereignty are developing messengers such as Matrix using decentralised messaging protocols. The adoption of such a protocol enables you to store data in the application developer's infrastructure. This software's messenger contains open source code, solid end-to-end encryption, and is decentralised. The Matrix-based system was developed by the French Armed Forces. In 2019, they developed the Tchap messenger to replace Telegram, which was previously used by local government departments for communication.

Germany

The German armed services also utilise the Matrix-based BwChat messenger for military communications. The messenger, developed with the help of the nation's Armed Forces' Cyber Innovation Center and Stashcat, provides a secure communication route not only while deployed in the country, but also when deployed overseas. Because of end-to-end encryption and mobile application management, it may be accessed from both professional and personal devices (MAM). In a safe communication environment that conforms with data security and GDPR, BwChat blends traditional chat features with cloud storage.

Each user gets their own file storage area and each conversation has its own storage space. User data is encrypted and handled in line with German data protection legislation in a server centre in Hannover.

The program allows for secure document sharing, an infinite number of conversation participants and the surveillance and organisation of movements using the "Share GPS Location" function. It is not dependent on the user's contacts list.

Switzerland

Except for the native messenger Threema, the Swiss Army prohibited all chat applications in 2022. The military can no longer use Signal, Telegram, or WhatsApp.

Because Threema does not require users to enter a phone number or email address when enrolling, no identity may be determined using publicly available information. At the same time, the messenger allows you to identify persons in your contact list by their QR codes.

Israel

In the year 2020, the IDF developed a messenger that was functionally equivalent to WhatsApp. It looks and operates just like WhatsApp, but it has additional privacy protections built in for sending extremely sensitive operational data, such as while conducting reconnaissance.

India

The Indian Army introduced its SAI texting app in 2021. It is comparable to commercial competitors WhatsApp, Telegram, and Signal in that it enables end-to-end encryption for voice, text messaging, and video conversations.

The Indian app offers enhanced security protections since all data is handled on local servers.

China

There is no open source information available on the Chinese military's usage of instant messengers. Furthermore, most major instant messengers and social networks, including Facebook, Instagram, Twitter, Whatsapp, Telegram, Viber, and even ICQ, are restricted in the nation. Local military troops are most likely using WeChat, the country's most popular and government-controlled messenger.

The safety and security of data are extremely important, particularly when it comes to the official communications of the military and in the institutions of the defence sector. Every officer in the armed forces is responsible for ensuring the safety and well-being of their colleagues. The success rate of successfully protecting secret and personal information is directly proportional to the level of security, encryption, and compartmentalization of the connection.

Quantum computers, which are very particular kinds of computers, are capable of solving problems in a very short amount of time, even those that would take a supercomputer a very long time to solve. It is true that doing these tasks is still a long way from being a reality, and quantum systems have many limitations. But, as we all know, progress is a never-ending process, and it is possible that in the not-too-distant future, this technology will rule the planet. Let's have a conversation about how this cutting-edge technology may impact our security.

Data encryption is the key to online security

Encryption is essential to the protection of data on computers and other Internets. Encrypting data entails utilizing a secret rule and a collection of characters, known as ‘the key’, to turn it into a meaningless jumble. To comprehend what the sender was trying to communicate, one will have to decode the ‘porridge’ using the key.

One of the most basic types of encryption is when each letter is replaced by a number (say, A - 1, B - 2, and so on). The word ‘breadfruit’ will appear like ‘2 1 15 2 1 2’ in this example, and the key will be the alphabet, where each letter corresponds to a number. Of course, more sophisticated rules are utilized, but the idea of the operation is roughly the same.

When there is only one key for all interlocutors, as in our case, such ciphers are referred to as symmetric. Before you may use a symmetric cipher, all interlocutors must acquire this key in order to encrypt and decode their own communications. Furthermore, it must be transmitted in an unencrypted format (after all, there is nothing to encrypt with yet). If you have to send the key over the Internet, attackers can intercept it and successfully spy on everything you've secured with it. This is not very practical.

As a result, there are encryption methods that employ two keys: private for decryption and public for message encryption (these keys are also called private and public). Both are the recipient's creations. He does not give the secret key to anyone, therefore he will not be intercepted.

The second, the public key, is intended to allow anybody to encrypt data with it, but it can only be decrypted with the accompanying private key. As a consequence, it is not frightening to send information in an unencrypted form — it poses no harm. This method of encryption is known as asymmetric.

Both the ‘lock’ and the ‘key’ (that is, public and private keys) in current encryption systems are typically huge integers, and the algorithms themselves are constructed on sophisticated mathematical processes using these numbers. Furthermore, operations must be designed in such a way that ‘turning them back’ is exceedingly difficult. As a result, having the public key will not assist someone attempting to break the cipher.

Quantum cipher cracking

What this means is that anything that is encrypted with a public key can only be decoded by its private ‘partner’, and no one else. This indicates that the private key is being investigated by potential adversaries. Because it is not sent to any location, as we have stated previously, it is not feasible to intercept it. However, in principle, one may get it from the general populace.

However, cryptographic methods are purposely intended to make it difficult to solve the challenge of acquiring a private key from a public key in a reasonable length of time. This is done by preventing the reverse engineering of public keys into private ones.

Quantum computers become useful at this point in the discussion. The simple truth is that, as a result of their design, they are capable of solving such problems significantly faster than conventional computers.

When a quantum computer is utilized, the unreasonably long amount of time needed to decipher a cipher can be reduced to a more manageable amount of time. And because of this, the very idea of utilizing a cipher that is susceptible to being broken by a quantum computer may be rendered moot in some theoretical sense.

The advent of quantum computers is imminent, and when they do arise, the world will be forever altered. Their introduction might completely change the way physics and medicine are practiced, not to mention the way that information is protected. So, how should we get ready for this?

Protection against quantum hacking

If the thought of your data being decoded and stolen by wealthy criminals using a quantum computer makes you cringe, don't worry: security experts are already planning for protection. Currently, there are some fundamental procedures in place that should protect user information from attackers.

Traditional encryption algorithms that are resistant to quantum attacks

It's difficult to believe, but we're already employing encryption methods that quantum computers can’t hack For example, despite quantum computers' increased speed, cracking the popular AES encryption used in instant messengers such as WhatsApp and Signal remains impossible. They do not pose a serious danger to many other symmetric (one-key) ciphers. we're back to the issue of distributing the key to all participants in the discourse.

Algorithms that are created expressly to thwart quantum assaults

Although no one is currently breaking asymmetric ciphers, mathematicians are actively developing new ones that are resistant to even the most powerful of quantum devices. So, by the time the bad guys get a hold of quantum computers, data defenders will almost certainly be able to strike back.

Encryption in several ways at once

Encrypting data numerous times with various methods is a useful and accessible approach. Even if attackers hack one one type of encryption, it is not guaranteed that they will be able to manage the rest.

Using quantum technologies against themselves

Quantum key transfer systems are employed for the secure usage of symmetric ciphers, which, as previously stated, are less resistant to cracking with the use of quantum computers. They do not ensure security from hackers, but they do allow you to be certain that the information was intercepted. If the encryption key is stolen along the route, you can refuse to accept it and send another one. True, this requires specialized technology, but it is very self-contained and operates in both government-backed and commercial businesses.

The entire internet will not be hacked

So, while quantum computers appear to be capable of breaking ciphers that regular computers cannot, they are not omnipotent. Furthermore, security measures are being created proactively to prevent attackers from gaining an advantage in the arms race.

So, the world's encryption is unlikely to fail all at once; rather, certain algorithms will ultimately be replaced by others, which is not always a negative thing. This is happening right now, because after all, technology is not a static industry.

As a result, it's occasionally worth investigating whatever encryption technique a certain service employs and whether the algorithm is regarded antiquated (susceptible to hacking). Indeed, supposing that the era of quantum computers has already arrived, it would be prudent to begin encrypting extremely important data meant for long-term preservation.

You want others to see your music video if you publish it on the internet. However, if your film is for corporate training, you don't want unauthorised persons to see your sensitive company information. Video encryption can keep unauthorised people from accessing your content.

Data breaches, illegal sharing and data theft are all dangers for modern businesses. To be competitive in today's world, you must rely on content security to keep your company's information safe and secure.

Encrypting your videos is one method of safeguarding your company's data. Once your video footage has been encrypted, you can safely share it with your employees, customers, partners, and prospects.

There are three ways to safeguard your videos from unwanted access: encrypting the video, protecting the video, or doing both.

What is encryption?

While encryption refers to the hiding or modifying of data, protection refers to safeguarding the file using codecs, passwords, container formats, and so on, all so that outsiders cannot access the data contained within.

However, for increased security, you can use both encryption and protection, which is the greatest solution for securing your content. In informal conversation, the term encryption can refer to encryption, protection, encoding, or any combination of the three. As a result, encryption in this context means securing your data in every way possible, which includes encryption as well as protection.

What exactly is video encryption?

The method of making your video secure from prying eyes is known as video encryption. Why should you encrypt your videos? There could be two explanations for this. The first is for personal use, and the second is for Digital Rights Management (DRM)

Personal encryption, as the name implies, is used to protect one's privacy. For example, suppose you make a film and want to share it with your relatives, mates, customers, and so on, but you don't want unwanted people to access it.

Digital Rights Management is similar in concept but more sophisticated. The various degrees of DRM are as follows:

– Software-centric video
– Adaptive streaming
– Qualitative and quantitative video streams for various price points
– Device or media-centric video
– Region-centric video

So, what exactly is the distinction between personal encryption and Digital Rights Management? Others are kept out of personal encryption except for the intended recipient. However, in the case of DRM, it either temporarily or permanently shuts people out, without human intervention and under certain conditions.

For various pricing ranges, qualitative and quantitative video feeds are available. – If you're willing to spend more money, you can obtain 4K, but if you want to save money, you'll have to settle for SD. It has an effect on the quality since it directly affects the resolution (physical data of the video stream). The higher the price, the higher the quality.

Region-centric video

Do you want to target a specific region? Perhaps you don't want the video to be seen in other areas or countries. The reasons for this type of DRM could be because you are legally prohibited from catering to other regions, or you want to influence market dynamics. In such cases, region-specific management is required.

Device or media-centric

This is done to prevent your material from playing on incompatible devices. You generate media that is limited to a specific device, such as iTunes, Kindle, or Apple TV. As such, those who do not adhere to the devices in question are unable to play it.

Software-centric video

To play some videos, you must have proper software support and/or pay a licence fee. Specific NLEs will not play certain codecs if the operating system does not support them or if the licence is not paid for. As a result, codec licensing is yet another method for controlling video consumption.

Adaptive streaming

During adaptive streaming, the video dynamically changes to the resolution and bit rate of the internet speed and/or other circumstances.

How are online videos kept secure?

The video is first encoded using conventional encryption and stored on a secure server. The video is not available for everyone to view. To view/access the movie, you must first log in to the server using a confirmed email address and password.

The video is delivered to the viewer's computer through a secure channel and may be watched using a browser that decrypts the video. The browser prevents unwanted access to other applications to see or record it. The browser also prevents the OS from storing the material on the viewer's PC. The secure connection ends as soon as the viewing is over. The data from the viewer is sent on to the content provider for targeted marketing and statistical study. You may also use this data to track down pilferages and leaks. And, if the video is accidentally downloaded, the encryption ensures that it does not play on the accessible media player.

How exactly does video encryption prevent piracy?

The "pirate" must have sufficient expertise to decrypt the encryption. To obtain a high-quality stream, pirates must pay up. And, of course, if you pay, the server will have the essential information about you.

To obtain an accessible format, the pirate must encode the encrypted stream using the software. The procedure either increases the file size or decreases the quality of the source. As the file size grows, the pirate must pay more money to transfer the data again. To detect correlations, cloud algorithms might use the uploaded material and compare it to the original stream.

Options for video encryption

When it comes to video encryption, there really are two scenarios: video at rest and video in action (streaming).

Video at rest

Here are some possibilities for videos that remain on hard drives or are downloaded to play later:

– AES encryption standard - 128, 192, or 256 bits
– Google Widevine
– Apple Fair Play for iTunes videos
– Marlin
– PMP (Protected Media Path) in Windows

Video in motion or video streaming

Some examples of video in motion or streaming video include:

– RTMFP and RTMP(E)
– HTML5 DRM standard

The Advanced Encryption Standard (AES), which has been approved by the government of the United States and is currently utilised all over the world, is the encryption method that provides the highest level of safety.

Nearly 20 years ago, the National Institute of Standards and Technology (NIST) established guidelines for secure passwords. Indeed, they are still used by many websites, portals, and other services. You’re likely familiar with these password requirements — there ought to be at least 8 characters, both capital and lowercase letters, digits, and special characters. Despite these guidelines, passwords that meet these requirements are no longer safe from modern attackers. The only thing any of us can do to improve the security of our accounts is to make sure that our passwords are lengthy, complicated, and unique for each account. Due to the strict password management requirements, this strategy is, nevertheless, laborious and intimidating for many.

The Same Password Rules Do Not Apply Today

In the modern day, password-based security is no longer seen as sufficient. Our digital world is continuously expanding, thus it is more important than ever to make sure that our data is safeguarded from cybercriminals. Cybercriminals perceive an opportunity to target people in a more sophisticated way as a result of the increasing usage of internet services. One explanation is that, although we benefit from technological improvement for our personal, social, or economic growth, cybercriminals have also benefited from the advantages of improved computer graphics cards and machine learning to enhance their attack strategies. In addition to the problem of more sophisticated cyberattacks, there are two interrelated problems with conventional password rules:

The first concern lies in our human nature — keeping track of passwords is tough

You may take a few steps as an individual to increase the security of your passwords. Start by lengthening and making your passwords more complicated. Second, create a unique password for each website you visit. The difficulty of remembering a password increases with its complexity. As a result, we frequently select passwords that are not entirely suitable yet are simple to remember. The difficulty of managing several complicated passwords for every online account leads to the frequent reuse of the same passwords across multiple platforms. As a result, a successful attacker immediately wins big.

However, the high level of password complexity necessary to maintain online safety should not be blamed; rather, it should be pointed out that we can’t improve our inadequate password management skills. Using a password manager to generate and store secure passwords is a useful solution. It is not humanly possible to manage strong passwords for all of our internet accounts without assistance, such as password managers. Because they can't recall the complicated, random sequences of letters, numbers, and special characters, the problem increases the likelihood that individuals will write down their passwords. Passwords are left exposed in digital files stored on a computer or in desk-top notes, making it simple for hackers to hack and read passwords.

The second problem is that passwords have a mathematical limit

There are only ever a finite amount of potential password combinations since a password is a mix of letters, numbers, and symbols. As a result, the best technique for breaking passwords is brute force attacks. Until the correct combination is identified and the password is broken, brute force attacks attempt all possible combinations of letters, numbers, and symbols. Theoretically, a stronger password would be one that is harder to guess due to its length, complexity, and number of possible permutations. However, attackers are now substantially more frequently exploiting Graphic Processing Units (GPUs) to break passwords. GPUs are a component of a computer's graphics card and were first designed to speed up the loading of images and movies. They now show promise for computing hashes (the method used in brute force attacks).

According to studies on password cracking times, passwords may be cracked much more quickly using sophisticated computer graphics cards. Using the most recent computer graphic cards, an 8-character password that used to take 8 hours to crack in 2018 now only takes 39 minutes (see the conclusive 2022 results in the table below). Passwords are gradually getting simpler to crack as a result of recent technical developments, which is a concerning trend. More crucial, however, is the fact that if a password has already been stolen, repeated across sites, or contains basic phrases, attackers may access your accounts right away, regardless of the complexity of the password or the attacker's graphics card.

Consider a 4-character password made up of all 26 letters in the Latin alphabet (case-insensitive) in order to visualise this mathematical example.

26^4 = 456,976 possible password combinations

The number of viable choices rises to when you include digits, uppercase and lowercase letters, and special characters.

95^4 = 81,450,625 possible password combinations

However, because the password must contain at least one special character, one number, one capital letter, and one lowercase letter, the quantity drops to

5,353,920 possible password combinations.

Nevertheless, assuming there are no password-entry security measures, this can be cracked in less than a second by a computer (such as automatic account blocking).

Increase the length and complexity of passwords

Longer or more complicated password phrases are strongly advised when creating new passwords. In this manner, potential attackers will have a harder time breaking the codes. It's crucial to take into account the popularity of the selected password combination in addition to the amount of alternative password combinations. For instance, lists of frequently used passwords or phrases, such as "qwerty," "password," or "12345," are frequently used in brute force assaults.

Therefore, the password should be completely unique or not contain any words at all. For instance, one technique would be to employ acronyms or mnemonics, such as generating a password out of the first few characters of a long text. As an illustration, consider making the password ‘Ilts@7S!’ out of the words I love to ski at Seven Springs.

Password length and complexity alone are insufficient

We are aware that adding length and complexity to passwords is the only method to increase their strength and, consequently, the safety of our accounts. The time it typically takes an attacker to break a password in 2022 using a powerful commercial computer is displayed below. This chart, which has been analysed and periodically updated since 2018, shows how quickly passwords can be broken on current machines. This pattern indicates that, despite our best efforts to create passwords that are longer and more complicated, passwords alone are no longer sufficient to meet the required internet security standards.

In conclusion, password rules increase the complexity of passwords without necessarily enhancing their security. The answer to that is to use no passwords at all. However, we’ll discuss that in part 2 of this article.