21

I have an asp.net application working in https (SSL). This is working well in my local computer and Amazon AWS(production environment).

But when I host this application in office (for testing) some strange things happens.

  1. I can see the https in browser and the lock sign.

  2. Fiddler also showing that the output is encrypted and shows port 443.

  3. But HttpContext.Current.Request.IsSecureConnection returns false

  4. And HttpContext.Current.Request.Url.Scheme returns http.

In the office we are using Juniper SSG firewall and TMG 2010 (Forefront Threat Management Gateway 2010). So server receive request through Juniper and TMG 2010. Thanks in advance.

Jomy John
  • 6,308
  • 4
  • 28
  • 32

3 Answers3

18

To reduce costs I suspect that the SSL certificate is installed on the TMG Gateway and that this gateway is simply rewriting the request to standard HTTP when passing it to the actual web server. So by the time the request hits IIS and your web application it is a standard plain HTTP request.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • SSL certificate installed in TMG – Jomy John Oct 04 '12 at 11:08
  • Alright, so this explains the behavior. TMG is rewriting the request before passing it to the web server. – Darin Dimitrov Oct 04 '12 at 11:09
  • 5
    @JomyJohn if the SSL *terminates* at the TMG, then ASP.NET is correct: the request that gets to ASP.NET is not https – Marc Gravell Oct 04 '12 at 11:09
  • @Darin Dimitrov Thanks, Can you suggest some solution ? – Jomy John Oct 04 '12 at 11:12
  • Configuring your web servers and managing SSL certificates is off-topic for StackOverflow. I invite you to head to SF if you have some specific questions about it: http://serverfault.com/questions/68753/does-each-server-behind-a-load-balancer-need-their-own-ssl-certificate One possible approach is to have a dedicated SSL farm of reverse proxies. – Darin Dimitrov Oct 04 '12 at 11:14
  • I will do . Thanks for the support. :) – Jomy John Oct 04 '12 at 11:19
  • @Jomy as a side suggestion - at a previous job when we had this on our F5 box, we wrote some TCL on the F5 that set a custom http header to tell us the original request was https. – Marc Gravell Oct 04 '12 at 11:20
  • @MarcGravell, while this would work for knowing whether the original request was HTTPS it would be problematic if you are using forms authentication in which you have set the `requiredSSL="true"` for the authentication cookie (which is a good practice). – Darin Dimitrov Oct 04 '12 at 11:22
16

This tripped my up after deploying to Amazon's Elastic Beanstalk environment. I couldn't see any way to get the load-balancer to allow the SSL request straight through to the server. Instead it was always terminating the SSL at the load-balancer and passing plain http back to the server.

I found this documentation: Elastic Load Balancing Concepts - X-Forwarded Headers.

Essentially the load-balancer injects a number of additional HTTP Headers into each request before forwarding it to the back-end server. The most relevant one is X-Forwarded-Proto which tracks the protocol used to connect from the client's browser to the load-balancer. This can be checked like so:

var loadbalancerReceivedSSLRequest = string.Equals(Request.Headers["X-Forwarded-Proto"], "https");
var serverReceivedSSLRequest = Request.IsSecureConnection;

if (loadbalancerReceivedSSLRequest || serverReceivedSSLRequest)
{
    // SSL in use.
}
else
{
    // SSL not in use.
}
sheikhjabootie
  • 7,308
  • 2
  • 35
  • 41
0

Well another way to check is to check the port

if(context.Request.Url.Port == 443)

Note: check which port is used for secure connections, usually it is 443

A Khudairy
  • 1,422
  • 1
  • 15
  • 26
  • This does not work as the web server still sees the request as port 80. – Aki Nov 23 '16 at 16:37
  • @Aki you might be right, but in the description "Jomy" mentioned that on fiddler he sees port 443 .... – A Khudairy Nov 24 '16 at 16:58
  • 3
    I think that is because Fiddler would show the request between client and load balancer which is encrypted (port 443). But the request between the load balancer and web server will show port 80 and that is what ASP.NET sees. – Aki Nov 28 '16 at 15:38