But not all web filters can block HTTPS websites. For example, some can block http://facebook.com but not https://facebook.com. This gives users an easy way around the filter resulting is more wasted time and greater risks for organizations. Popular sites – including Facebook, YouTube, and LinkedIn – have recently adopted the HTTPS standard. This is good news for security but bad news for companies that use a web filtering that cannot block https sites or require an additional component to be purchased to do so.
Every organization needs the ability to allow or block HTTPS sites. Reasons :
#1. Increase productivity
In the past HTTPS was used for online transactions, banking, and other sensitive sessions. These days even websites that do not handle sensitive data are adopting HTTPS. Social networking sites like Facebook, Twitter, YouTube are often blocked by businesses for some employees but these sites now use HTTPS by default. For a small business, having a web filter in place that can block HTTPS is the only practical way to prevent wasting time on these sites.
#2. Block dangerous websites
There are millions of risky websites on the internet that have a history of transmitting malicious software or supporting online fraud. Techniques like spoofing, drive-by-downloads, session hijacking, and other tactics, can infect a users PC with malware. These techniques work on HTTP sites and HTTPS. The HTTPS filter helps protect businesses from these hazards.
#3. Block offensive web content
Websites containing inappropriate content is commonplace across the web. These sites can also use HTTPS. The only way an organization can protect themselves is to use a web filter that can manage both HTTP and HTTPS sites.
Many industries are required to have enhanced network security. Some standards, such as the Children's Internet Protection Act (CIPA), require organizations to filter web content. Any industry that requires HTTP filtering is all but certain to require HTTPS filtering as well, for the reasons outlined above.
TLS is a critical part of the IT infrastructure. For example, HTTP is secured with TLS, and, voila, we have HTTPS. So web sites use TLS to secure communications between their servers and web browsers. TLS is also widely used to secure the following protocols:
Simple Mail Transfer Protocol (SMTP) may use TLS to access certificates to verify the identity of endpoints. Vendors have created VPNs based on TLS, such as OpenVPN and OpenConnect. Such VPNs have advantages for firewall and NAT traversal compared to traditional IPsec VPNs. TLS is a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS/SSL is not the default on many websites or portions of websites. A 2014 study of one million websites showed that only about 450,000 supported TLS as opposed to older SSL https://jve.linuxwall.info/blog/index.php?post/TLS_Survey .
In fact, the TLS/SSL websites more often than not are completely different from their unsecured counterparts; it is not a matter of simply replacing http:// with https://. For instance, the TLS-secured version of http://en.wikipedia.org/wiki/ is https://secure.wikimedia.org/wikipedia/en/wiki. That is why the Electronic Frontier Foundation offers the HTTPS Everywhere add-on for browsers. The add-on activates TLS security features if they are present on websites, but it cannot create them if they do not already exist.
The Trustworthy Internet Movement, which scans for SSL vulnerabilities on the world’s most popular 20,000 websites, reported in January of 2016 that 64% of sites they surveyed had inadequate security.
We know that SSL is insecure. As of 2014 the 3.0 version of SSL has been considered insecure as it is vulnerable to the POODLE attack that affects all SSL block ciphers. SSL 3.0’s implementation of RC4, the only non-block cipher supported, is also feasibly broken. This leaves us with TLS. This protocol has been revised several times to address security vulnerabilities. Just as with any unpatched software, using older versions can lead to exploit of vulnerabilities that have already been remediated.
TLS can be transmitted using Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). TCP has more secure features than UDP. In either case, TLS transmissions can be compromised using TCP or UDP vulnerabilities. Ditto for public key cryptography, ciphers, and key exchange.
TLS has been integrated into many software packages using and open source libraries. A paper presented at the 2012 ACM conference on computer and communications security showed that few applications used some of these SSL libraries correctly, leading to vulnerabilities. The Heartbleed bug affects the popular OpenSSL library, allowing attackers to steal private keys from servers.
The weakest point of an SSL/TLS connection is the key exchange. If the key exchange algorithm is already known by the attacker and the server’s public key has been compromised, in theory that system is open to man-in-the-middle attacks. The attacker would then be able to monitor the client surreptitiously. HTTPS reserves a single port, TCP port 443, for key exchange. Thus distributed denial of service (DDoS) attacks need flood a sole port in order to bring an organization’s network to a standstill.
The Trustworthy Internet Movement reported that 91% of websites were vulnerable to the BEAST attack, in which an attacker can theoretically use features of the encrypted data to guess its contents.
Some websites support older SSL/TLS for backwards compatibility. As of June 2016, Trustworthy Internet Movement estimates that 26% of websites offer such “protocol fallback”. But this can be an opportunity for protocol downgrade attacks such as DROWN, which affects OpenSSL. Full details of DROWN were announced in March 2016, together with a patch for the exploit. At that time, more than 81,000 of the top 1 million most popular sites are among the TLS-protected sites vulnerable to the DROWN attack.
If your organization exclusively uses the most up-to-date TLS implementation and takes advantage of all TLS security features, you are ahead of the game. In order to protect your organization from nefarious exploits cloaked under the secrecy of SSL, you need a web filter or web gateway that has the capability to intercept and decrypt SSL traffic. The idea behind this is relatively simple in theory.
The web filter creates a secure connection between the client browser and the filter and then and decrypts the outing SSL traffic into plain text upon which the traffic is analyzed. Once reviewed, the traffic is re-encrypted and another secure connection is created between the Web filter and the Web server. This means that the Web filter is effectively acting like an SSL proxy server and so can both intercept the SSL connection and inspect the content.
Google has announced that its web browser Chrome will soon take a more aggressive stance on web encryption, marking any site as insecure if it doesn’t use HTTPS. The rollout will begin in January by applying the rule to any site that asks for a password or credit card information. Eventually, Chrome will label all HTTP sites as insecure.
The WebTitan web filtering solutions scans encrypted traffic in a manageable and affordable way. The ability to scan https traffic eg. web mail and most social networks is a thorn in the side of many businesses that use a web filter that cannot block https or require an additional component to be purchased to do so. The cost and inconvenience can be substantial.
WebTitan can provide you with an extra layer of granular control for HTTP & HTTPS filtering with AD integration. SSL Inspection allows WebTitan to process encrypted HTTPS traffic. Put simply, HTTPS is SSL layered over HTTP. It achieves this by performing man-in-the-middle decryption and re-encryption of the HTTPS traffic, inspecting the contents of the unencrypted HTTPS traffic.
With WebTitan, HTTPS filtering is included as standard. In fact, standard service includes every security feature we offer and free technical support. Give your organization uncompromising powerful security with WebTitan.
Sign-up for email updates...