Mozilla moves its DNS over HTTPS protocol testing to Beta phase

Mozilla Firefox is all set to test DNS over HTTPS feature on its beta channel.

As an effort to safeguard user security, web browser Mozilla began experimentation with DNS (Domain Name System) in early June 2018. The new experiment revolved around DNS over HTTPS (HyperText Transfer Protocol Secure) protocol – which uses encryption to secure the DNS requests and responses. In August, the web browser carried out several tests in the Nightly channel to see whether the new protocol had any impact on the browser speed and performance. After a successful test, the company is now planning to test this technique on their beta channel.

DNS over HTTPS aims to address the data leak vulnerabilities that exist when data is exposed in DNS and by recursive resolver, when it searches for any IP address or domain. Mozilla hence launched two new features – Trusted Recursive Resolver (TRR) and DNS over HTTPS (DoH) to fix these vulnerabilities.

Data can be at risk if the operating system uses an untrustworthy resolver that can tamper the response or even track user requests like on-path routers. DoH will protect user data against on-route tampering and eavesdropping. Mozilla also said that it has been working with Cloudflare on this, which is providing a recursive resolution service with pro-user privacy. Cloudflare’s service removes all personally identifiable data between every 24 hours, to ensure that no data is passed along to any third party.

Mozilla added the DoH support to Firefox 62, but not as a default setting. Users need to configure the settings in their browser system.

The August survey results revealed minor performance impact when using HTTPS with a cloud service provider, on non-cached DNS queries. The queries were slower by six-milliseconds, which per the testing team was an acceptable cost for all the benefits it could bring in terms of securing user data. The results also found that the slowest DNS transactions could now perform better with the DoH feature than the traditional ones.

Image Source: Mozilla

We hypothesize the improvements at the tail of the distribution are derived from 2 advantages DoH has compared to traditional DNS. First, is the consistency of the service operation – when dealing with thousands of different operating system defined resolvers there are surely some that are overloaded, unmaintained, or forwarded to strange locations. Second, HTTP’s use of modern loss recovery and congestion control allow it to better operate on very busy or low-quality networks.” – per the company blog.

The Beta Channel experiment will also use Cloudflare’s DoH service. The company will be releasing an initial rollout to selected beta users in the United States following September 10.


Chrome will stop showing secure padlock icon for HTTPS websites from September

From September 2018, with the release of Chrome 69, the websites with SSL certificates will not show the green address bar, HTTPS wording and the padlock icon.

With most of the websites on internet adopting HTTPS, Google said that the websites without any indicators will be safe by default.

Currently, the Chrome shows “Secure” indicator with a padlock icon for secure websites, and “HTTP” for websites that are not secure. The ‘S’ in the HTTPS stands for secure.

The uncertified websites can migrate to HTTPS by installing an SSL certificate. SSL reduces the risk of confidential information from getting into the hands of hackers and thieves.

With Chrome v69, the “Secure” wording will be removed and only the padlock icon will be visible for secure websites.

Further, with the release of Chrome 70, Google will remove the padlock icon as well.

Chrome 69 and Chrome 70

“We’ll step towards removing Chrome’s positive security indicators so that the default unmarked state is secure,” wrote Emily Schechter, Product Manager, Chrome Security, in a blog post.

Using Chrome version 70, if a user enter data on a HTTP website, the browser will start flashing a red “not secure” warning in the web address bar.

Chrome 69 not secure

“We hope these changes continue to pave the way for a web that’s easy to use safely, by default. HTTPS is cheaper and easier than ever before, and unlocks powerful capabilities – so don’t wait to migrate to HTTPS!” added Emily Schechter.

Also read: Let’s Encrypt to now issue free Wildcard certificates through ACMEv2

Cloud News News Web Security

Let’s Encrypt to now issue free Wildcard certificates through ACMEv2 

Let’s Encrypt, the non-profit certificate authority, has announced that wildcard certificates and ACMEv2 will now be supported. With this announcement, Let’s Encrypt takes a step ahead to make HTTPS adoption easier and to make the web a more secure place.

Wildcard certificates work same way as typical SSL certificates, but allow a website to secure multiple sub-domains of the main domain with a single SSL certificate. For example, for a website ‘domain.cxm, a Wildcard SSL certificate can secure ‘blog.domain.cxm, ‘login.domain.cxm, ‘newsroom.domain.cxm, etc.

Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases,” wrote Josh Aas, ISRG Executive Director in Let’s Encrypt blog.

Currently, there are more than 53 million active Let’s Encrypt certificates on the web.

Let’s Encrypt has also launched version 2 of ACME (Automatic Certificate Management Environment) protocol. ACME is a communication protocol used to automate the interactions between a certificate authority and its users’ web servers, making automated deployment of public key infrastructure possible at a very low cost.

The authorization/issuance flow in ACMEv2 is faster than its v1 version. Let’s Encrypt has changed the JWS request authorization in v2, along with ability to rename directory endpoint/resource and URL in challenge resources.

In ACMEv2, the ‘resource’ field of JWS (JSON Web Signature) request bodies has been replaced by a new JWS header. Users will be able to create account and ToS (terms of service) agreement in a single step rather than two. ACMEv2 aims at making the management of certificates easier.

Also read: Cybercriminals using trending topics like Bitcoin and FIFA 2018 for phishing scams: Kaspersky Report

The websites who want to implement Wildcard certificates will need to use ACMEv2. Let’s Encrypt has not stopped ACMEv1 yet, since a lot of subscribers use this protocol.

The requests for Wildcard certificate will need websites to modify the DNS (Domain Name Service) TXT record, to prove domain ownership.


Every Wi-Fi enabled device vulnerable to a new security attack called KRACK

Security researchers have discovered weaknesses in the WPA2 (Wi-Fi Protected Access II), the security protocol for most modern Wi-Fi networks. An attacker within the range of victim can interrupt credit card numbers, passwords, photos, and other sensible information using the bug called KRACK (Key Reinstallation Attacks).

What this means is that the security built into Wi-Fi is likely ineffective, and we should not assume it provides any security. If the security problem which researchers have discovered is true, then it will be very difficult to fix it. Because the WPA2 is built into almost every internet connected device.

During the initial research, it was found that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others are all affected by some variant of attacks. The attacks against Linux and Android 6.0 or higher devices could be devastating because these devices can be tricked into (re)installing an all-zero encryption key. Currently 41% of Android devices are vulnerable to this attack.

It is also possible that attackers can inject and manipulate data depending on the network configuration, such as ransomware or other malware data into websites.

US Homeland Security’s cyber-emergency unit US-CERT confirmed the news of vulnerability on Monday and described the research this way- “US-CERT has become aware of several key management vulnerabilities in the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security protocol. The impact of exploiting these vulnerabilities includes decryption, packet replay, TCP connection hijacking, HTTP content injection, and others. Note that as protocol-level issues, most or all correct implementations of the standard will be affected. The CERT/CC and the reporting researcher KU Leuven, will be publicly disclosing these vulnerabilities on 16 October 2017.”

Most of the protected Wi-Fi networks including personal and enterprise WPA2 networks are affected by the KRACK and are at risk of attack. All the clients and access points that were examined by researchers were vulnerable to some variant of the attack. The vulnerabilities are indexed as: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088.

“The weakness lies in the protocol’s four-way handshake, which securely allows new devices with a pre-shared password to join the network. If your device supports Wi-Fi, it is most likely affected,” said Mathy Vanhoef, a computer security academic, who found the flaw.

Changing the passwords is not going to work even if you set a strong one. So, update all your devices and operating systems to the latest versions. As of now, users can protect themselves by sticking with sites that have HTTPS security, and keeping the Wi-Fi off. Since the security issue is related to Wi-Fi, the attacker has to be within a range, and the odds of widespread attacks are apparently low.

Also read: Many organizations unprepared for DNS attacks, reveals new global survey

The warning came at Black Hat security conference, and is scheduled to be formally presented on November 1 at ACM Conference on Computer and Communications Security (CCS) in Dallas.


Google’s new HSTS list to tighten up browser security

Google recently announced HTTPS Strict-Transport Security (HSTS) preload list as a measure to improve web browser security.

With this, Google plans to enforce HTTPS for all sites lying within its own TLDs (top-level domains) like .google, .soy and .how.

Google has always tried to ensure security of the web. It is not the first time that it has introduced a measure to secure sites. Earlier in 2010, it announced HTTPS as default for Gmail and then again, in 2014, made HTTPS a standard to boost a website’s rank in Google search and to encourage HTTPS usage. Recently in 2016, it also become the gold sponsor for Let’s Encrypt SSL certificates.

Now, as the wider next step to boost HTTPS adoption, Google has switched to HTTPS strict transport security for many of its TLDs.

Per the HSTS policy, browsers will automatically use HTTPS encrypted connection to sites that support HTTPS. This means, even if the user hits on the address bar, the browser will switch to HTTPS.

This policy will protect sites from attacks like POODLE that weaken and aim to strip out encryption.

The HSTS list will support all major browsers (Chrome, Internet Explorer, Safari, and Opera). It will include a list of hostnames for which the selected browsers will automatically enforce encrypted HTTPS connection.

The preload list can contain individual, sub-domains and even TLDs that are added through the HSTS website. Google currently operates 45 TLDs.

The provision to add TLDs as a whole under the HSTS list will ensure that all domains under them are secured by default. So, the registrants simply need to choose a secure TLD for their website and configure an SSL certificate. They do not need to worry about adding individual domains or sub-domains to the preload list of HSTS.

Google plans to make these secure TLDs available for registration soon.

Articles Hosting Technology Web Security

Understanding HTTPS, Types of SSL Certificates and Installing a SSL certificate for Microsoft Exchange 2007

With security risks becoming increasingly rife in the Internet, SSL has become a vital entity to ensure the protection of the organizations. SSL, basically, is a security protocol designed to ensure the authenticity of a website’s integrity and the website’s content.

Now, what SSL does is that it encrypts the data being transmitted between the source and destination, of course, after a secure connection is established between them. Websites involving money transactions and membership procedures, secured with SSL, are protected from cyber crimes very effectively and smoothly.

Ok, SSL protects your websites. So far, so good. But how do visitors or customers of a particular website confirm that it is secured and its safe for them to share their data here?

After having a SSL installed on your website, your URL changes from HTTP to HTTPS. This ‘HTTPS’ in the URL confirms the presence of the SSL security. HTTPS helps you keep hackers away from your website by covering up users’ confidential data from the rest of the world. The video below will help you get better hold of the idea:

Over the years, SSL has undergone many changes like: previously SSL was able to provide just 40 bit of encryption which has now been extended to 256-bit level along with 2048 bit level encryption future proof certificates.

Now there are various types of SSL certificates available. Before going deep down into types of SSL certificates and their uses I would like to tell you that SSL certificates are issued and signed by a trusted third party called Certificate Authority (CA).

Categories of SSL Certificates:

  • Free SSL: Many web hosting companies provide free SSL. If the data on your website is not of utmost importance, you can think of getting this kind of SSL. Else, its a total no-no.
  • Shared SSL: Websites having this kind of SSL act as sub domains of the main web hosting provider and hence share the SSL certificates. What it means is that the shared SSL will not display your domain name but instead your web hosting provider’s.You can use shared SSL certificate in situations where you need secure connection to a server that is not typically seen by the general public. For example, when logging into the administration area of your website.If you own an e-commerce website, a shared SSL is a strict no-no because visitors expect to see your domain in the URL, which as already explained, shared SSL does not display. And if you attempt to use your domain name with the shared certificate, your website may or may not work. Even if it does, the visitors will see the shared SSL warnings (please see the figure below) which will most likely put them off, and they won’t share their credit card or any other confidential with you.
  • Dedicated SSL: Dedicated SSL, for dedicated hosting plans allow customers to choose their domain names. This type of SSL certificates, though costly, are the best ones when it comes to the fulfillment of fully fledged security needs.Ideal for situations when the general public needs to access your website, Dedicated SSLs are the best option for protecting credit card information for e-commerce websites, since customers see your domain name in the URL instead of web hosting provider’s, making them feel comfortable while their data.
A likely occurrence if you use a Free SSL Certificate

Types of SSL Certificates:

Along with the above categories, SSL certificates depending upon the needs can be differentiated into following types:

  • Domain Validation or DV SSL: These types of SSL certificates secure the domain validity of a particular website. Here, the contact info of the website is detailed in the WHOIS database of the website’s domain.
  • Organization Validation or OV SSL: OV SSL, as the name suggests, ensures the authenticity of the website’s business organization along with its physical know how and other web addresses.
  • Extended Validation or EV SSL: Most complex and trusted security validation, EV SSL provides the enhanced authenticity to a particular website/organization. EV SSL shows its uniqueness by changing the color of the website’s address bar in to green.
Different types of SSL Certificate validation

Installing a SSL certificate for Microsoft Exchange 2007:

As far as the installation of SSL certificates is concerned, Microsoft Exchange is the foremost difficult one to be tackled with. Difficult because it demands a great level of case sensitivity as it demands each and every element of information to be entered exactly as it is.

First of all, drag the Microsoft Exchange 2007 program and create a request for the Exchange 2007 certificate, using the Certificate Request Generating tool online. After this, import the Microsoft Exchange 2007 certificate by actually downloading the certificate.cer and copy the certificate’s thumbprint.

After the completion of the above steps, you just need to enable it via a command:

Enable-Exchange Certificate-Thumbprint <thumbprint>-Services “SMTP”, “IIS”

This will enable OW, auto discover and SMTP security. If you want to modify/change the commands for the POP, IMAP, UM or IIS, you can do that. Also make sure that you always check for the SSL certificates updates to avoid the SSL disturbances and expiry dates.