SSL Proxy

HTTPS Interception
ARTICA v 4.30.000000
Page 1
Artica v4.x : http://articatech.net | contact: contact@articatech.com | support: http://bugs.articatech.com
T ABLE OF CONTENTS
Introduction................................................................................................................................. 4
The benefits of HTTPS interception .................................................................................................................... 5
Detect malware downloads: ....................................................................................................................................................................................... 5
Detect C&C traffic: ......................................................................................................................................................................................................... 5
Detect exfiltration: ......................................................................................................................................................................................................... 5
Bypass HTTPS weaknesses: ........................................................................................................................................................................................ 5
Display correctly error pages: .................................................................................................................................................................................... 5
Speed: ................................................................................................................................................................................................................................... 5
Reasons against HTTPS interception................................................................................................................... 6

Strict transport security ............................................................................................................................................................................................... 6
Whitewashing ................................................................................................................................................................................................................... 6
Disrupts personal use .................................................................................................................................................................................................... 6
Certificate transparency .............................................................................................................................................................................................. 6
Disrupts BYOD:................................................................................................................................................................................................................ 7
Discourages good practices by the users .............................................................................................................................................................. 7
Limited benefits ............................................................................................................................................................................................................... 7
Hard-shell-soft-inside ................................................................................................................................................................................................... 7
Unknown reasons ............................................................................................................................................................................................................ 7
Known behavior without HTTPs interception with Artica .............................................. 8

Using some proxy ACLs may not work ............................................................................................................... 8
Deny requests provide browsers connection errors ....................................................................................... 9
Enable HTTPS Interception ................................................................................................... 10

Create a self-signed Root CA............................................................................................................................... 10
Why not an official certificate ? .............................................................................................................................................................................. 10
Use the Certificate center ........................................................................................................................................................................................ 10
Download the PFX ....................................................................................................................................................................................................... 11
Affect the certificate to a proxy port. ................................................................................................................ 12

Using transparent – WCCP method .................................................................................................................. 13
SSL rules .................................................................................................................................................................... 14
Deny some websites to be decrypted. ................................................................................................................................................................. 15
Certificate on browsers .......................................................................................................... 18

Microsoft Internet Explorer, Google Chrome or Opera ................................................................................ 19
Mozilla Firefox ......................................................................................................................................................... 20
The Web filtering error page behavior. .............................................................................. 22
Proxy errors pages behavior.................................................................................................. 24
Page 2
SSL Interception monitor ....................................................................................................... 25
Display generated certificates ............................................................................................................................. 25
Page 3
INTRODUCTION
Year by year the HTTPS traffic growth and the world going to provide a WWW(s).
Thanks to innovative projects like Let’s Encrypt, adoption of HTTPS is rising steadily: in mid-2015 it was at 39%, now it’s at 51%
of HTTPS requests.
Over 90% of the world’s HTTP traffic was expected to be secured over SSL/TLS by the end of 2019.
More and more SSL stats suggest that we’re getting closer to a 100% encrypted web. Browsers with a huge market presence,
such as Chrome and Firefox, are truly putting in the effort to get us there as fast as possible. However, divergent UI policies will
probably delay the whole process and cause users to suffer in the meantime.
97% of all traffic to Google in India is encrypted. (Source: Google’s Transparency Report)
India shares the first place with the UK and Japan. The next group of countries, where 95% of all traffic to Google is encrypted,
consists of Indonesia, Mexico, and Brazil. They’re followed by France with 92%, and Russia and the US, where 91% of traffic is
encrypted.
90% of pages loaded in Chrome in the US were over HTTPS in May 2019. (Source: Google’s Transparency Report)
In comparison, 4 years ago it was only 45% of pages.

The rising trend is clearly noticeable among all countries included in the report. Germany is second with 89%, rising from 35% 4
years ago. France is next with 88% of pages loaded over HTTPS, followed by Russia and Mexico with 82%.
HTTPS usage stats about other browsers show the same uptrend. 78% of all pages loaded in Firefox are over HTTPS.
Page 4
THE BENEFITS OF HTTPS INTERCEPTION
From Marnix Dekker, IT Security Strategy and Policy, European Commission (March 8, 2017)
Detect malware downloads:

In most cyber-attacks the end-user is triggered to download malware or an infected file, for example via a phishing attack, a
waterhole attack or a malvertisement attack. HTTPS interception would allow the network proxy to see the binaries and
documents downloaded and this means they could be scanned, by comparing with known malware signatures or by opening
documents in sandboxes.
Detect C&C traffic:

Command & Control traffic to exotic domain names and IP addresses is the hallmark of an infected device calling back to the
attacker’s infrastructure. To avoid detection, attackers have started to use legitimate websites for C&C traffic, for example a
Twitter feed of a burner Twitter account. Without HTTPS connections you can only see there is an Internet connection with
Twitter. So it blends in with normal user traffic. HTTPS interception would allow the Internet proxy to see also the content, for
example which Twitter accounts are accessed. This could in principle be used to distinguish C&C traffic from normal user
traffic.
Detect exfiltration:
Attackers could use HTTPS connections to exfiltrate data. In principle HTTPS interception could be used to detect if corporate
documents or files are being uploaded, for example by looking for known patterns, markers or headers in documents.
Bypass HTTPS weaknesses:

You’d be forgiven for having lost patience after more than a decade of problems with HTTPS: First slow adoption by websites,
then bad issuing practices by Certificate Authorities (CAs), then security breaches at CAs, then lax implementation by
browsers, and finally we have trained all end-users to click blindly on “Yes” or “Can I continue now” with each warning message.
Intercepting HTTPS before it reaches the browser or the end-user could in principle be used to bypass the issues with the
browsers and the end-users.
Display correctly error pages:

HTTPS interception allow the proxy to interact with the SSL tunnel . In this case, browser displays correctly blocked request
using the proxy generated errors instead of displaying just a connection error.
Speed:
HTTPS interception can be implemented relatively quickly, especially if you already have a proxy in place for outgoing Internet
connections. Most products in fact offer it as a simple add-on. Of course the work of implementation does not end here (see
below) but making changes to endpoints, such as installing software or hardening, could take much longer and require a lot of
work.
Page 5
REASONS AGAINST HTTPS INTERCEPTION
Strict transport security
HTTP Strict Transport Security (HSTS) is an Internet standard allowing websites to tell the browser to never accept non-
HTTPS connections.
This is important when a user forgets to type the S in the URL and it prevents from stripping attacks.
A similar thing is done with cookies.
If the website sets the cookie with a secure flag, then the browser will not send it back without HTTPS.
These protections are important to prevent man-in-the-middle attacks.

It also means you cannot just remove the SSL/TLS connection without breaking things.
So intercepted HTTPS connections will have to be re-encrypted by the intercepting proxy.
This is a kind of impersonation/spoofing.
Part of the deal with HTTPS interception is that connections are re-encrypted with a fake certificate, a wildcard certificate (*),
which is valid for all websites.
This is a kind of impersonation or spoofing, except that it is done with good intentions.
The wildcard certificates are in fact not sold by real CAs, but an enterprise could create one with a non-official internal CA.
This wildcard certificate then needs to be installed on all the PC’s in the enterprise.
Whitewashing
Re-encryption with wildcard certificates effectively makes the browser and the user blind.
The browser will no longer be able to warn the user about HTTPS connections and the end-user has no way to see if the
certificate is valid and if the connection can be trusted.
The original certificate is whitewashed.
This would not be a problem of course if the intercepting proxy is perfect and flawless, refusing all the bad connections,
accepting only the good ones.
But this is a tall order.

A recent report actually shows that many of these interception products are very bad when it comes to accepting certificates,
effectively opening the door to all sorts of attacks (decryption, downgrade or stripping attacks).
This raises some liability questions.
Disrupts personal use

Social media, webmail providers and online banks ask their users to verify the HTTPS connection.
In the case of HTTPS interception this is impossible.
Maybe HTTPS interception requires some legal disclaimer about liability.
But apart from the legal matters, many employees would no longer use their corporate PCs for things like social media,
personal web mail or web banking.
In some settings this is not a problem, for most organizations it is important to allow some form of personal use of corporate
PCs, for example to allow employees during their break to make a bank transfer or buy their groceries online.
Certificate transparency
It is not enough to re-encrypt connections with wildcard certificates.
Certificate transparency is an extra protection measure allowing browsers to check if a certificate is normally used by that
website.
A browser like Google Chrome, for instance, warns users when a Google page is shown with a different certificate, even if it is
formally valid.
It is a reaction to the continuous security problems and breaches at CAs.
It is an important feature and it helped to discover the large-scale MITM attack on Iranian Internet users, aka the Diginotar
breach.
So HTTPS interception requires you to tweak also the browser to accept the masquerading of the original certificate without
complaints.
Certificate transparency needs to be turned off.
At this point it should be clear that HTTPS interception involves not only a quick intervention at the network monitoring box,
but that it actually involves changing how endpoints, browsers, and ultimately the end-users, handle HTTPS connections.
Choosing HTTPS interception has wider implications for IT at the organization.
Page 6
Disrupts BYOD:
Employees are increasingly using their own personal computers in the office and for work. Sometimes devices are used side-
by-side with corporate devices.
To implement HTTPS interception personal BYOD devices will need to be tweaked and configured, to install and trust the
wildcard certificate, and to turn off browser warnings.
This not only leads to a lot of work by the IT department, which runs counter to the very idea of BYOD, but it is also likely to
raise some eyebrows with users. HTTPS interception does not play well with BYOD.
Discourages good practices by the users

Even if we ignore BYOD, there is also the problem that employees have personal devices for personal use.
Social media, online banks all ask end-users to inspect certificates and to heed browser warnings.
With HTTPS interception in the enterprise and no HTTPS interception at home, the employee is dealing with two worlds:
At work all HTTPS connections look strange, but they are to be trusted.
At home when HTTPS connections look strange it is an attack.

This is confusing for the end-user and this creates risks.
Limited benefits
The benefits of HTTPS interception are small and will diminish:
 Malware detection is failing.

Attackers evade signature-based detection by using polymorphic malware.
Sandbox-based detection is being evaded also.
It is easy to see that traditional signature-based antivirus programs are losing the battle.
In fact it is much more important to keep systems updated then to install extra software to detect malware. Network
monitoring tools cannot do better than AV (only worse actually).
 Attackers also know how C&C traffic is detected

so they hide it.
For example there are attacks in which the C&C communications are hidden in JPG images posted on Twitter
timelines. In these attacks HTTPS was not even used by the attacker!
The problem is not the HTTPS encryption but the fact that there is a sea of communications to hide in.
 The same applies to exfiltration.

For an attacker obfuscation is more important than encryption.
If needed attackers (insiders and outsiders) could always use an extra layer of cryptography.
 Perhaps the most compelling reason for HTTPS interception

is to bypass the flaws in the browsers and the weakness of the end-user ignoring warnings.
But also this benefit is diminishing.
Browsers are implementing HTTPS better. It is harder for users to ignore HTTPS warnings.
Hard-shell-soft-inside
HTTPS is an extension of network monitoring and detection.
Investing in network monitoring and detection now is like betting on the horse that is lagging behind and visibly tired.
Not only is it easy for attackers to evade detection, it is a continuation of the traditional approach based on securing the
corporate perimeter (hard-shell-soft-inside).
It is known that this approach is flawed and it also clashes with the increased mobility of staff and the uptake of cloud services.
Implementing HTTPS just goes further down the wrong path.
Unknown reasons
 You did not need decrypting HTTPS for Web filtering.
 You did not need decrypting HTTPs for defining WAF ACLs
Page 7
KNOWN BEHAVIOR WITHOUT HTTPS
INTERCEPTION WITH ARTICA
When you not perform HTTPs interception:
USING SOME PROXY ACLS MAY NOT WORK

If you want to filter access to web page using :
Any object playing with URLs/HTTP headers/Browsers identification will not work
The following objects cannot be used when surfing on SSL sites:
 Files extensions
 Smartphones
 Browser
 SSL SNI domains
 Mime type (GET)
 Mime type (reply)
 Web server filename reply
 URL expression
 Regex matching on URL path
 Referer URL expression
Page 8
DENY REQUESTS PROVIDE BROWSERS CONNECTION ERRORS
If you block a website, when users need to access to this Website, a connection error is displayed on the browser.
This because the proxy :
 Sends an HTTP error as the browser ask SSL protocols ( Deny ACL ).
 Redirects the connection by return a 302 location that cannot be understood before the exchange certificate (Web-
filtering ).
Page 9
ENABLE HTTPS INTERCEPTION
CREATE A SELF-SIGNED ROOT CA
Why not an official certificate ?
An official certificate is only valid for *.yourdomain.com domain.
It is indeed wildcard but the wildcard applies only to subdomains of yourdomain.com.
When HTTPS decryption is enabled the sites being decrypted and re-encrypted are completely different, for example
www.google.com.
Using an official certificate did not make sense and did not avoid the trust browser SSL issue.
Browsers must trust the Root CA of your proxy.

You have to establish the trust by adding the Proxy Root CA certificate to the list of trusted root certificates.
Use the Certificate center

 On the left menu, click on “Your system” / “Certificates Center”
 Click on New Certificate button.
 The first step is to create a Certificate Request, fill the form properly and pay attention to the Common Name that
should the Web error page hostname and proxy name.
 Click on Generate the Certificate Request button,.
 Your certificate in on “Not generated” status, this is normal, only the “Certificate Request” is generated
 Click again on the certificate link to open its properties.
Page 10
Click on the Generate New Certificate button
This will build a new Self-signed certificate based on your parameters.
Download the PFX

 Click on the archive icon on the PFX column.
This PFX will be used to deploy the certificate in the browser certificates container.
Page 11
AFFECT THE CERTIFICATE TO A PROXY PORT.
 On the left menu, choose “Your proxy” / “Listen ports”
 Click on the port you want to enable the HTTPS Interception.
 Turn on the “Decrypt SSL” checkbox

 Select your generated certificate in the “Use A Certificate From Certificate Center” dropdown field.
 Click on “Apply configuration” on the main table and confirm
Page 12
USING TRANSPARENT – WCCP METHOD
The transparent method did not use the same method.
In connected mode, the listen port can act as HTTP and HTTPs interception mode.
In transparent method, you need to create separately an HTTP port and an HTTPs port
Our first port hook destination 80 port. We need to create a second port to hook the 443 port.
 On the transparent section, create a new port

 In destination port, type any SSL port you want to hook ( basically the 443 port)
 Choose the certificate that enable the SSL interception.
Page 13
SSL RULES
Even if you have enabled SSL interception in the proxy ports, websites are still not decrypted.
By default, the proxy check all certificates but did not decrypt the protocol.
If you want to decrypt all websites or some websites, use the SSL rules.
On the left menu, choose Your Proxy / SSL protocol and SSL Rules
You have 2 choices:
1) Turn the default rule to decrypt all websites and create rules that deny decrypting websites
2) Keep the default rule to not decrypt websites and specify which websites you want to decrypt.
The standard behavior is the option 2, let test decrypting all websites.
We click on the default rule and enable the “Decrypt SSL” checkbox.
Then Click on “Apply rules” on the main table in order to put rules in production mode.
Page 14
Deny some websites to be decrypted.
Some Websites, banking websites, governments websites detects that browsers pass trough an SSL interception method and
refuse to generates web page.
In this case, you need to “whitelist” a set of websites.
 Create a new rule

 Turn OFF the “Decrypt SSL” option
 Click on Add button
 Click on the created rule

 Choose Proxy objects tab.
 Click on “New object”
 Click on choose under type field.
Page 15
 Search “SSL SNI” and choose SSL SNI Domains.
 This object is able to check domains directly in certificates.
 In this case, all Websites that handle the defined domain will be not decrypted.
 Set the name of your object

 Click on Add button
Page 16
 On the new object, click on the “add” button in the row.
 Add main domains in the list.
 Finally, click on Apply rules in the main section.
Page 17
CERTIFICATE ON BROWSERS
If you have enable HTTPS on the proxy and set default rule to decrypt all websites, going to goole.com cause the certificate
claim about
NET::ERR_CERT_AUTHORITY_INVALID
This because the proxy have decrypted the google website and re-encrypt the protocol with a new certificate built with its
private key.
www.google.com website using a dedicated self-signed certificate and the browser did not trust the Authority used by the
proxy.
Page 18
MICROSOFT INTERNET EXPLORER, GOOGLE CHROME OR OPERA
Both Microsoft Internet Explorer, Google Chrome , Opera and any other Chromium derived browsers use the same system
storage for root certificates.
The following screenshots show steps required to install Root Certificate into system certificate store.
After you have downloaded the PFX right-click on it and choose “Install PFX”
Click on next button at the Click on next on the

File to import screen
Welcome Certificate Import wizard screen
Page 19
On the Certificate Store screen,
Set the password field empty and click on next
click on Browse button and select “Trusted Root Certification
Authorities” and click on next button
Trusted Root Certification Authorities

Click on “Finish” button at the end of the wizard
Must be selected, click on Next button
On the security warning message box, click on “Yes” button

You will see a success importation message box.
MOZILLA FIREFOX
The best way is to enforce Mozilla to trust Microsoft Windows Root store
Create a file named root-trust-microsoft.js in o Firefox's C:\Program Files (x86)\Mozilla Firefox\defaults\pref directory.
In the . root-trust-microsoft.js file add this line
pref("security.enterprise_roots.enabled", true);
On the next start Firefox will trust your CA add in Internet Explorer.
This setting applies system-wide for all users.
Page 20
After importing the certificate, you will see that the new connection to google.com is secure.
If you see the certificate used for the website
You ill see that is issued by your self-signed certificate.
Page 21
THE WEB FILTERING ERROR PAGE BEHAVIOR.
If you using the web filter engine, you have to define the redirect page.
On the left menu, select “Web-filtering” / “Error page” and click on the Wizards button
 Define the hostname as the same name defined in the Common Name of your certificate.
 Ensure this hostname point to the IP address of the proxy in order to display the web page.
Page 22
Using HTTPs interception, the proxy is able to send correctly the redirection page.
By default the proxy redirect blocked requests to the HTTP web page.
By default the option Redirect HTTPs to HTTPs is set to OFF.

It means that a blocked HTTPs request will be redirected automatically to the HTTP web page.
Page 23
PROXY ERRORS PAGES BEHAVIOR
If you deny SSL sites or if an SSL site cannot be fetched by the proxy, the proxy is unable to send error content in the SSL tunnel.
The browser will display it’s own error and just displaying a connection error.
If you enable HTTPs interception, the proxy error page is correctly displayed
Page 24
SSL INTERCEPTION MONITOR
DISPLAY GENERATED CERTIFICATES
Under the SSL protocol, click on “Certificates”.
You will see all generated certificates by the proxy ( generated each 10 minutes ).
Take a look on the last column, you will see the issuer.
The issuer is important and must be the same of the certificate installed on your browsers.
If you change the proxy certificate you need to “Rebuild the SSL cache” by clicking on the “Rebuild SSL cache” button.
Page 25

SSL Proxy

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSL Proxy

Uploaded by

Copyright:

Available Formats

HTTPS Interception

Reasons against HTTPS interception................................................................................................................... 6

Known behavior without HTTPs interception with Artica .............................................. 8

Enable HTTPS Interception ................................................................................................... 10

Affect the certificate to a proxy port. ................................................................................................................ 12

Certificate on browsers .......................................................................................................... 18

The Web filtering error page behavior. .............................................................................. 22

Proxy errors pages behavior.................................................................................................. 24

In comparison, 4 years ago it was only 45% of pages.

Detect malware downloads:

Detect C&C traffic:

Bypass HTTPS weaknesses:

Display correctly error pages:

These protections are important to prevent man-in-the-middle attacks.

But this is a tall order.

Disrupts personal use

Discourages good practices by the users

At home when HTTPS connections look strange it is an attack.

 Malware detection is failing.

 Attackers also know how C&C traffic is detected

 The same applies to exfiltration.

 Perhaps the most compelling reason for HTTPS interception

USING SOME PROXY ACLS MAY NOT WORK

The following objects cannot be used when surfing on SSL sites:

Browsers must trust the Root CA of your proxy.

Use the Certificate center

Download the PFX

 Turn on the “Decrypt SSL” checkbox

 On the transparent section, create a new port

You have 2 choices:

 Create a new rule

 Click on the created rule

 Set the name of your object

 Finally, click on Apply rules in the main section.

Click on next button at the Click on next on the

Trusted Root Certification Authorities

On the security warning message box, click on “Yes” button

In the . root-trust-microsoft.js file add this line

This setting applies system-wide for all users.

You ill see that is issued by your self-signed certificate.

By default the option Redirect HTTPs to HTTPs is set to OFF.

You might also like