1

I have been given a task to test some of our company's security. I have SSL stripped before but on a very basic level and now days with the security is a bit harder.

I want to allow all HTTPS traffic but what I want to do is decrypt and re-encrypt so the webserver does not throw a fuss, because most web servers now force SSL so rather than try and fight it I want to go with it and do the attack this way.

What would be the best way for me to achieve this?

schroeder
  • 125,553
  • 55
  • 289
  • 326
TheHidden
  • 4,315
  • 3
  • 22
  • 40
  • possible duplicate of [How can my employer be a man-in-the-middle when I connect to Gmail?](http://security.stackexchange.com/questions/63304/how-can-my-employer-be-a-man-in-the-middle-when-i-connect-to-gmail) – Eric G Jul 10 '15 at 15:21

2 Answers2

2

You can't authenticate as the server

The problem is not that the server will "throw a fuss" it won't. You can easily spoof the server into thinking you are the user. The user isn't authenticating with an SSL cert. The problem is you can't trick the user or more specifically the user's browser. Remember for a MITM attack the attacker needs to establish connections with both entities (hence in the middle).

Client <---------> MITM Attacker <----------> Server

With http it is trivial. You sit in the middle and pretend to be the server to the client and pretend to be the client to the server. The problem with https isn't the link between you and server (as far as the server is concerned you are the client). The problem is in the link between you and the user.

When user browses to https://example.com the browser will expect:

  • That an SSL cert is returned
  • That the SSL cert has example.com in the hostname
  • That the SSL cert is signed (or indirectly signed) by a root cert in its trusted root keystore.

If you block the client from getting the ssl cert from example.com the browser will give the user an error (http timeout)

If you send the user a valid (signed by a CA) cert for another hostname the browser will give the user an error (incorrect hostname)

If you send the user a cert for example.com which you create and it is not signed the browser will give the user an error (cert not trusted).

If you send the user a cert for example.com which you sign by another CA cert you control the browser will give the user an error (cert not trusted) because it doesn't trust your CA cert.

SSL Strip (redirecting the user to http)

How SSL Strip works is by redirecting the user from https to http. User browses to http://example.com and you intercept that send the user a redirect to http://example.com and still establish a secure connection between you and the server.

Client <--- HTTP ---> MITM Attacker <---- HTTPS ---> Server

Understand you are potentially compromising the user to other real attackers. If the user is connecting by say company wifi anyone on the wifi could steal sensitive information because you have stripped off the ssl.

The user however may notice they are on http not https (why is my bank website not showing green bar). Sadly this is not that common most users will just blindly assume they are secure so HSTS was developed to protect users from this type of attack. If browser supports HSTS, the site is using HSTS, and the user has been to the site before (or HSTS was preloaded by the browser) the user will get an error/warning when you redirect to http.

"Infect" user's computer with a "trusted" root cert that you control

The only way around HSTS (especially with preload) is to create a CA cert which you have the private key for and the install that in the browser/os of the victim. Then when you MITM the user you can create a cert for example.com, sign it by your MITM CA cert. The browser will validate the example.com cert you created and check the signature which will be valid and come from a cert it trusts (in the trusted root keystore). This will require administrative access on the user's machine.

Even this will not work if the key pinning has been used in the browser to make a note of the "real" example.com cert.

Community
  • 1
Gerald Davis
  • 2,260
  • 16
  • 17
  • Your example has a mistake but since it's missing only a single character I can't make the edit (minimum 6 characters on edits). `http://example.com` should be `https://example.com` in the first of the two links – d0nut Jul 10 '15 at 16:35
  • Thanks for this, I am glad you understood my question (I am very poor at getting my point across) This is what I wanted to know. I have done the "infect" before using a squid -ssl proxy system. I shall read through this vigorously – TheHidden Jul 15 '15 at 10:24
0

What are you asking for? Technical details or legal aspects?

Technical details will rely on your company's infrastructure. In general, you have to create your own Certificate Authority, install its certificate as trusted in company's computers and then generate false certificates for each domain you want to test.

Legal aspects cover 2 things:

  1. Company traffic.
  2. Employee's personal traffic (eg. to bank accounts).

First, you should sign an agreement with your company, allowing you to make required tests and (explicitly) possibly intercept company's internal information, even information not meant for your knowledge.

Second, all employees affected by your test should be written informed that their network traffic is monitored and can be intercepted and even manually analyzed. Note that each country can have specific legal requirements for such information (for example employees can be required to agree on that during signing job agreement).

Tomasz Klim
  • 1,456
  • 12
  • 13
  • as a tech company this is tests on closed networks on products so its all gravy in that aspect. in regards to technically do you have any links? What I have done previously is set up a squid proxy and done it that way but at the momment I am looking at mitmproxy – TheHidden Jul 10 '15 at 11:39