Every day, new cyberattacks are threatening companies’ defense systems, and further weaken relations with web users, particularly on e-commerce websites. Identity theft and data theft have become common.
The risks of a malicious person intercepting the data transmitted by the web user on your website and more generally all the information transmitted between the browser and the server of your website ,are increasing significantly.
Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, the solution to implement against these risks.
On November 17, Mozilla released the version 83 of the Firefox browser, promising improved performance in terms of page loading and browsing responsiveness, as well as a significant reduction in the memory used.
But above all, Mozilla introduces a brand-new security feature to the small world of browsers, an “HTTPS-Only Mode” option to limit browsing to secure HTTPS* connections only.
Image source: Mozilla Security Blog
Mozilla is pushing it further regarding the desire of major browsers to pass HTTPS as the default browsing protocol instead of the unencrypted and therefore fully visible HTTP.
Which display during browsing?
When the option is activated, any web page that does not have an SSL/TLS certificate (allowing the HTTPS and the security padlock icon to be displayed in the browser address bar) will be preceded by the warning message below, which is restrictive for web users.
Image source: Mozilla Security Blog
What to expect in the coming years?
If the option is not yet activated by default, Mozilla’s management indicates that it expects HTTPS to become the standard for browsing the Web. Driven by the successive evolutions of browsers and their increasingly obvious displays of a lack of security, more and more websites are migrating to HTTPS by default. It is likely that browsers makers will decide to completely depreciate HTTP connections in the near future, making HTTPS the default protocol for Web browsing.
How can companies be prepared?
Most companies have already begun the migration of their website(s) to the HTTPS by default. It is important to maintain an exhaustive inventory of the company’s websites and pages and to control the associated SSL-TLS certificates, of which the main risks are renewal errors and poor implementation. It is essential to set up clear procedures and to associate to them a good communication towards the interlocutors in charge of the websites. Actors such as Nameshield are there to accompany you in this process. They have the expertise and tools necessary to simplify these tasks and reduce the risk of error.
TLS/SSL certificates are used to authenticate servers (mostly Web) and encrypt traffic between websites and users. Thus, they ensure the integrity of the data exchanged and prevent data spying. The digitalization of the company and the world in general, as well as the browsers’ desire to impose HTTPS:// by default, have multiplied exponentially the need for certificates.
To meet these growing needs, the wildcard certificate (*.domainname.com) is increasingly being considered by companies. While it has some advantages, particularly in terms of costs reduction and flexibility, it is important to be aware of the disadvantages in order to choose the right certificate wisely. A brief overview of the wildcard certificate.
What is a wildcard certificate?
A standard TLS certificate secures an explicit host name (CN for Common Name or FQDN for Fully Qualified Domain Name) defined in its metadata. For example, Google holds a certificate for mail.google.com.
This certificate is only valid for: https://mail.google.com/
It cannot be used for: https://google.com/ – https://images.google.com/ – https://my.mail.google.com/
In other words, the host name must be an exact match. If you try to use this certificate on https://my.mail.google.com/ you will get a certificate error from your browser.
A TLS wildcard certificate is different. As its name implies, it uses a generic match rather than an exact match. This generic match is represented by “*” in the CN and covers all subdomains of the same level. Example with the *.google.com certificate.
This certificate is valid for: https://mail.google.com/ AND https://images.google.com/ as well as all possible subdomains of google.com.
It cannot be used for: https://google.com/ (without subdomain) or https://my.mail.google.com/ (the subdomain level is not the same).
The practical side of the wildcard certificate?
In some situations, the wildcard certificate is very useful. A host that proposes websites for different clients, hosted on a shared server, and accessible through different subdomains… client1.mysite.com, client2.mysite.com, client3… It is less practical, technically more complicated and de facto more expensive to ask for a new certificate for each client that registers; the simplest option is a wildcard certificate for *.mysite.com, a unique certificate that will cover all clients. The case is identical for a company that wishes to access its websites through FQDN derived from the same domain and hosted on the same web server, *.mycompany.com. So far, everything is okay.
But then, what is the risk?
In the cases above, all sites are hosted on a single server. In large companies, or for major websites, hosting is often more complex and on different servers. Let’s take again our example of Google with images.google.com and mail.google.com, these two applications are linked to different services of the company, hosted on different servers and managed by different technical teams. This kind of organization is extremely frequent in the company. And this is where the security of wildcard certificates stops.
The problem with wildcard certificates, and to a lesser extent with certificates containing multiple entries (the famous SAN, Subject Alternative Names), comes from the fact that they are deployed on several servers. Indeed, to ensure the security of a TLS/SSL certificate, it is absolutely necessary to protect the private key associated with the certificate. Ideally, it should be stored in a vault or in a HSM. When a certificate is installed on several servers, the associated private keys circulate, increasing the exposure to the risk of compromise.
Case of a compromised certificate
In case of a compromised certificate, or an error on the certificate (renewal problem), it is recommended to intervene quickly to limit the damage caused. Application for a new certificate (or renewal), installation of the new certificate and, if necessary, revocation of the compromised certificate.
In our example of creating websites on a single server, this is not a problem. We have only one server, it has been compromised, the stolen/expired/compromised certificate only works for this one server; we have limited the damage as much as possible.
In a “several servers” scenario, if the certificate of only one of the servers is affected, it becomes compromised on all of the servers, which will have consequences on all of them and require a much wider intervention to repair the damage, most often in an emergency, and assuming that all of the affected servers are identified. Indeed, it is not uncommon for the certificate to circulate within several teams and to be installed without being listed on a certain number of servers. The impact can be important.
Taking our example of Google. Let’s imagine that only the images.google.com server has been hacked and that mail.google.com has not been affected. The certificate for images.google.com being a wildcard certificate for *.google.com which is common to mail.google.com, the cyber-attacker having compromised the images service has by rebound usurped the identity of the mail.google.com server and can intercept the traffic of the mail service while this server has never been hacked!
Good practice: one TLS/SSL certificate per server…
In our last example, if we were to have two certificates instead of one, with each server having only access to its own certificate, we would have limited the risk. In an ideal world, each certificate should only be used for one server (or a homogeneous cluster of servers). Different services on different servers should have their own certificates, generally not wildcard certificates.
A wildcard can be used if you have a lot of host names, of subdomain type, pointing to the same service on the same server. Be careful however that this generic certificate does not also cover host names pointing to other servers, in which case each service should have its own certificates.
Lastly, if you have a few host names pointing to single servers and everything else on a single service, then it is better to disassociate the host names. For example, you may have a certificate for login.mysite.com and a (wildcard) certificate for *.clients.mysite.com. On this last example, if the number of clients is fixed or clearly defined, it is better to go for a certificate with a precise SAN list, to better control secure host names and not allow the httpS:// on uncontrolled host names.
Conclusion
The option of a wildcard certificate exists and it is a good thing for some very specific needs. But in practice, there should never be a need to install a wildcard certificate, nor should the same certificate be installed on different servers not built in cluster.
October is the month in Europe that celebrates cybersecurity. Every year, the aim of this operation is to make users aware of digital security issues, both on a personal and professional level.
Many players are mobilized on this occasion to alert on cyber risks and inform on existing protection measures.
It is in this context that the website cybervictime.netwas launched!
This website is a digital manual of easy to implement solutions to protect your computer and your digital life.
You will find interesting tutorials about the security of:
your computer ;
your mobile phone;
your digital life and the protection of your personal data;
Domain name is the first link between the web user and your website. It is thanks to the domain name that you are found on the Internet, that you are visible, that your identity is displayed and that you develop your business on the net. It is a digital asset of your business.
The management and configuration of these domain names usually requires access to a management interface. The absence of a security policy can be dramatic.
Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, practical solutions to secure your access.
According to a joint report by iYouPort, the University of Maryland, and the Great Firewall Report, TLS connections using the preliminary encrypted SNI extension (ESNI) are being blocked in China. A new step towards censorship and a desire to be able to track Internet users.
What is SNI (Server Name Indication)?
When an Internet user consults a website in HTTPS://, it means that the site is secured by an SSL/TLS certificate. The consultation of the website begins with the establishment of the secure connection, the “handshake”. This handshake consists of several steps and aims to check the certificate and establish the encryption level of the connection. The first message of a TLS handshake is called “client hello”. With this message, the client asks to see the TLS certificate of the web server. The server must attach the certificate to its response.
Presenting the right certificate poses no problem in the case of dedicated hosting: one IP address, one certificate, possibly containing several SAN (Subject Alternative Name) belonging to the same organization. The problem occurs with shared hosting where the host has the same IP address but wants to install several different certificates, otherwise he will have to be the owner of the certificate by adding SAN for all his customers. Not a recommended practice.
The SNI responds to this specific request from hosting providers and their shared hosting. With the SNI protocol, the client indicates the hostname with which it tries to start a TLS negotiation. This allows the server to present several certificates for the same IP address (but different host names). The SNI could be compared to the apartment number of a postal address: a building has several apartments, so each apartment must be identified by a different number. Similarly, if the server is indicated by the IP address, client devices must include the SNI in their first message to the server to indicate which website (which apartment) they are trying to reach.
What is ESNI (Encrypted Server Name Indication)?
The establishment of an encrypted TLS connection begins at the end of the handshake. Problem, the SNI is not encrypted because the “client hello” message is sent at the beginning of the TLS handshake. A hacker can reconstruct the path of an Internet user by reading the SNI part of the handshake, even if he is not able to decrypt subsequent communications. The main interest for the pirate is to be able to trick the Internet user by creating a phishing site. On the other hand, the major web players like confidentiality, and wish to preserve the confidentiality of users’ browsing data. The ESNI was therefore born.
The ESNI (Encrypted server name indication) encrypts the Server Name Indication (SNI) part in the TLS handshake. The ESNI extension is accessible through the latest version of the TLS protocol, 1.3, which is being increasingly adopted today. The principle is to retrieve an encryption key through DNS (which can be secured through DNS via HTTPS). Still at the draft stage, some large hosting providers are already implementing it.
And China in all this?
In their report, iYouPort, the University of Maryland and the Great Firewall Report, detail how China views handshake encryption in a very negative light. This effectively prevents the Chinese government’s Great Firewall monitoring tool from seeing what Internet users are doing online. China has therefore decided to simply block HTTPS connections established through the latest version of the TLS protocol (1.3) associated with ESNI. In addition, the IP addresses involved in the connection are temporarily blocked for two to three minutes.
Some circumventing methods exist… but until when?
All three organizations appear to have found circumventing methods to apply on either the client side (in applications and software) or the server side to evade the current blocking implemented by the Great Firewall. ” Unfortunately, these specific strategies may not be a long-term solution: as the cat and mouse game progresses, the Great Firewall will likely continue to improve its censorship capabilities“, write the three organizations in their report.
In a new study of August 2020, INTERPOL measured the impact of COVID-19 on cybercrime. The results reveal that while the primary targets of cyberattacks usually remain individuals and SMEs, these have significantly expanded to large organizations and governments during the COVID period, revealing a new underlying trend.
The fact that working from home was massively implemented has obviously increased vulnerabilities which cybercriminals have been able to exploit seeking to take advantage of the situation.
According to this study, between January and April 2020, 907,000 spam messages, 737 malware incidents and 48,000 malicious URLs, all related to COVID-19 were detected.
The most common cyberattacks during the COVID-19 period were as follows:
Phishing
Ransomware
DDoS
Data harvesting malware
Cybersquatting / fraudulent domain names
Fake news
In Europe, two-thirds of member countries report a major increase in the number of cybersquatted domain names containing the keywords COVID or CORONA and ransomware deployments on critical infrastructures.
Cloning of official government websites is increasing massively as cybercriminals seek to steal sensitive data that can be used in future attacks.
In this report, you will discover all the measures implemented by INTERPOL.
It is more crucial than ever to secure your domain names carrying critical services and to protect your infrastructures.
Our consultants are, of course, at your disposal to assist you on these points.
Reverse DNS is often unknown to domain name managers, especially when the names are hosted by major hosting companies. Reverse DNS allows you to resolve from an IP address to an FQDN. This is the exact opposite of the classic use of DNS, which associates domain names to IP addresses. The reverse DNS allows to answer the question: I have an IP address, what is the FQDN related to it?
Reverse DNS operates by creating a reverse DNS zone in which DNS PTR records (for Pointer Record) will be configured.
Classic DNS: Record A: we know the name of a site and we want to obtain its IP address…
Reverse DNS PTR: we know an IP address and we want to retrieve the name of the site.
The resolution system is constructed in a similar way to the classic resolution. To perform DNS resolution, the IP address to be queried is configured in the reverse zone with the suffix .arpa and points to the required destination. The principle is the same for IP v4 and v6 addresses according to the following construction:
Ex: IPv4: 11.80.92.81.in-addr.arpa. IN PTR capp.perf1.com.
Ex: IPv6: 0.0.0.0.0.0.0.0.0.1.0.1.0.0.0.0.0.8.c.0.0.1.0.a.2.ip6.arpa. 4080 IN PTR capp.perf1.com.
This construction enables to operate a classic DNS resolution on a domain name with a “.arpa” extension.
Why is this so important?
Reverse DNS is mainly used to track the origin of a website visitor, the origin of an e-mail message, etc. It is usually not as critical as the classic DNS, visitors will reach the website even without the presence of reverse DNS for the IP of the web server or the IP of the visitor.
However, Reverse DNS is important for one particular application: the e-mail system.
Many mail servers on the Internet are configured to reject incoming mail from any IP address that does not have reverse DNS. For those who manage their own mail server, reverse DNS must exist for the IP address from which the outgoing e-mail is sent.
Regardless of the address to which the reverse DNS record of the IP address points, a reverse DNS record is expected. In case of hosting several domains on a single mail server, it is enough to configure the reverse DNS to point to the domain name considered as the main one (mail servers checking the reverse DNS recognize that it is normal to host many domains on a single IP address and that it would be impossible to list all these domains in the reverse DNS for IP). We recommend that you check the possibility of setting up reverse DNS with your DNS hosting solution.
Every year, the Club of Experts in Information and Digital Security (CESIN) publishes its barometer of companies’ cybersecurity in order to better understand the perception and concrete reality of cybersecurity and its issues within CESIN member companies.
Last January, CESIN unveiled the results of its OpinionWay survey, carried out from the 2nd of December 2019 to the 7th of January 2020 among its 253 members, Chief Information Security Officer (CISO) of major French groups.
Cyberattacks: Fewer companies affected but still heavily impacted
First of all, the study highlights a positive figure: the decline in the number of companies that suffered at least one cyberattack in 2019, i.e. 65% of the companies surveyed compared to 80% in 2018 (note, however, that this difference in results is nuanced by the addition of the definition of cyberattack in the survey conducted in January 2020).
On the other hand, the impact of these cyberattacks remains significant since 57% of these attacks have consequences on business such as disruption of production (27%), website unavailability (17%) and revenue loss (9%).
The targeted companies were the targets of 4 types of cyberattacks on average in 12 months. Among the attacks vectors, phishing remains the most frequent attack with 79% of companies affected in 2019, followed by the scam on the President (47%), the exploitation of a vulnerability (43%) and fraudulent login attempts (40%).
The main consequences of these attacks are identity theft (35%), malware infection (34%), personal data theft (26%), ransomware infection (25%) and denial of service (19%).
Cloud, IoT and AI, issues of concern
With the digital transformation, the use of the Cloud is important within companies: 89% of companies surveyed store their data in a Cloud, including 55% in public Clouds.
A massive use of the Cloud which still represents a high risk due to a lack of control over the hosting provider’s subcontracting chain (for 50% of CISOs), the difficulty of conducting audits (46%) and the lack of control over the use of the Cloud by employees (46%). For 91% of respondents, the tools implemented by Cloud hosting providers are not sufficient to secure the data stored, and specific additional tools or measures are necessary.
Connected objects are also a growing concern, increasing the attack surface and creating new types of threats. The CISOs surveyed are concerned about the security breaches present in this equipment (43%) and the uncertainty in the assessment of potential risks (28%).
The study also shows that the embedded AI at the heart of cybersecurity solutions has yet to prove its worth since 53% of CISOs do not trust it.
An awareness of cyber-risks
To prevent the risk of attacks, companies implement an average of a dozen protection solutions, in addition to antivirus and firewalls. Among them, the mail security gateway (85%), the VPN/SSL gateway (85%), proxy and URL filtering (83%), and multi-factor authentication. The latter, adopted by 72% of companies, has increased by 13% compared to 2018.
More aware of cyber risks, 91% of the companies surveyed are implementing a cyber-resilience program in parallel with protection solutions or are considering doing so, that’s 12 points higher than last year.
Awareness of cyber risks is also reflected in the steady increase over the last three years in the number of companies having subscribed to cyber-insurance (60%).
Despite this, only 4 out of 10 companies say they are prepared in case of a large-scale cyberattack.
Employees Awareness
In addition to the external threat, for 43% of companies, employees’ negligence is the most common cyber risk.
Shadow IT, i.e. the deployment and use of applications and services beyond the control of IT teams, is mentioned by 98% of the CISOs surveyed and remains a significant threat to be dealt with.
Yet even though they are aware of cyber risks (according to 74% of respondents), only half of employees comply with the recommendations, according to CISOs.
Issues for the future of cybersecurity
Governance is the first issue mentioned by CISOs (70%) for the future of cybersecurity, followed by users’ training and awareness raising on cybersecurity issues (57%).
Increasing the budget is another major issue for 50% of respondents. The proportion of the IT budget allocated to cybersecurity has increased in companies compared to last year. 62% of them plan to increase it further in the next 12 months and 83% want to acquire new technical solutions.
In terms of human resources, one out of two companies (51%) would like to increase the number of staff dedicated to cybersecurity, but 90% face a shortage of Information Systems Security profiles, leading to recruitment difficulties.
Let’s Encrypt was recently the subject of discussions in the small world of TLS certificates, by suddenly revoking 3 048 289 certificates which should not have been issued. A bug in its validation software prevented CAA registrations controls, and the certificates in question should not have been initially issued. These significant disruptions resulted from this mass revocation, but it is difficult to complain about a free service.
I am often asked what I think of Let’s Encrypt, and I always have this same answer: Let’s Encrypt has done a lot to encrypt the web, but is undermining the security of the web. Encryption allows to ensure confidentiality (no one can spy on) and integrity (no one can modify) of exchanges. But encryption alone is not enough if I do not have any guarantee of the identity of the one I am exchanging with (legitimate or fraudulent?)… And that is the whole problem.
In 2015, the Let’s Encrypt initiative supported by leading players of the Internet (EFF, Mozilla, Cisco, Akamaï…) was created with the purpose of massively and freely spreading SSL certificates to the whole world. More than five years later, the organization secures 190 million websites and has just announced that it has issued a billion certificates. The milestone was reached on February 27, 2020. This is undoubtedly a great performance.
96% of the web encrypted in January 2020
In 2015, less than half of the web traffic was encrypted, to reach 96% in January 2020. Of course, Let’s Encrypt is not the only player responsible for this rise. Edward Snowden launched the first alert, Google has largely stepped into the breach, between referencing policy and changes in web security indicators. But by providing to all, free certificates based on a largely automated system, Let’s Encrypt has democratized encryption… and put the concept of identity into oblivion.
No identity, no security
Let’s Encrypt’s credo is simplicity, to “simplify to the extreme HTTPS deployment and put an end to its horribly complex bureaucracy” (says EFF in the launch campaign). The horribly complex bureaucracy has however a meaning: high authentication, which guarantees the identity of the certificate’s holder. Maybe not the absolute guarantee of legitimacy, not a guarantee of content either, but the guarantee of a registered company, legitimately owner of the concerned domain name and with a certificate validated according to a drastic procedure.
Let’s encrypt merely verifies the domain name’s control (DV, Domain Validation). One only has to click on a link in an email or to fill in a TXT record on the domain name’s DNS zone. Yet domain names registration in most TLDs is purely declarative. It is quite easy to register a domain name, to request a certificate from Let’s Encrypt and to publish a website in HTTPS://.
The results?
In five years, all phishing and fraudulent websites have switched to HTTPS://. Since 2016, Vincent Lynch alerted on this problem, 15 270 certificates with the term “Paypal” had been issued by Let’s Encrypt, 14 766 of these certificates were fraudulent.
The market has been brought down in terms of authentication level. Let’s Encrypt is far from being the only one responsible, Google and Mozilla, with their 70% of market shares, have largely supported the initiative, the big Cloud hosting providers followed, as well as the Certification Authorities, challenged on the prices. Today we have a secure web with 77% (November 2019) of certificates whose proprietary’s legitimacy is not verified.
High authentication changes the game
The web has become encrypted by default. Does that make it more secure? Nothing is certain. The web user educated for twenty years to check the presence of the padlock in the address bar, trusts a web where all the fraudulent websites display the security padlock. Today, Internet is confidential but that does not make it safe.
It is urgent to return to high authentication. High authentication ensures a set of compulsory, drastic and controlled steps in order to obtain certificates. The procedures are enacted by CA/B Forum, regularly strengthened, and followed by audit from Certification Authorities.
23% of the certificates are still issued on the basis of high authentication, mostly in the corporate world, where CISO are pushing to preserve it. We all have to rely on them and support initiatives supporting OV (Organization Validation) and EV (Extended Validation) certificates, especially EV to guarantee the identity of the websites visited by web users. While identity on the Internet seems to have been somewhat forgotten for some time in favor of confidentiality, it is likely to come back to the spotlight again soon, driven in particular by web users and the need of personal data protection.
Nameshield uses cookies
Nameshield wishes to use cookies to ensure the proper functioning of the site and, with our partners, to measure its audience🍪.
Nameshield wishes to use cookies to ensure the proper performance of the website and, with our partners, to monitor its audience. More information in our Cookie Policy 🍪.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
CookieLawInfoConsent
1 year
Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
_ga
2 years
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_gtag_UA_25904574_14
1 minute
Set by Google to distinguish users.
_gid
1 day
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
NID
6 months
NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
