CSS SSL Termination w/HTTPS rewrite

Answered Question

I'm terminating SSL on the CSS for a website that we want to force users to use HTTPS to get to the site. If the user uses HTTP we want the Load balancer to change it to HTTPS have the user use the HTTPS url for all queries to the site.

I've looked at a couple of ways of doing this. One method is to create a special 'service' entry which rewrites the URL. But I don't see how this can work with the normal way SSL terminated websites are configured.

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a00801de8d6.shtml

is the example of that.

Alternately there's the 'ssl-server 1 urlrewrite 1 www.domain.com' command, but that seems to only cause backend webserver issued redirects to get changed from http to https. It doesn't cause the incoming request to be changed.... ?

Thanks.

I have this problem too.
0 votes
Correct Answer by jason.espino about 7 years 2 months ago

You are correct. The IP address is bogus on the example you have provided. Your redirect service does not require an IP address in order for it to work properly.

The configuration you have posted should accomplish what you are requesting however you will need to add a new content rule:

service ssl_module

add ssl-proxy-list ssl-list1

keepalive type none

type ssl-accel

slot 2

active

service redir-https

keepalive type none

type redirect

no prepend-http

domain https://www.domain.com

active

owner domain

content http

vip address

port 80

protocol tcp

url "/*"

add service redir-https

active

content http

vip address

port 81

protocol tcp

url "/*"

add service web-service

active

content ssl

vip address

protocol tcp

port 443

add service ssl_module

advanced-balance ssl (if you want to maintain stickyness for SIDs)

application ssl (Reuse of SIDs for HTTPS connections)

active

The reason for the alternate port content rule(I just chose port 81, but any port can be used) is to allow the decrypted HTTPS connection/traffic to be handled to the webserver for processing. If you do not have the alternate port your HTTP connection will fall into a redirect loop if you have the proxy-list configuration setup to forward the decrypted traffic back to port 80. This pattern will continue and the browser will never be able to resolve content.

Redirect loop will occur with the following:

ssl-server 1 cipher all-cipher-suites 80

Content will be displayed correctly as the CSS can forward the decrypted traffic to an alternate port content rule for the webserver to process the connection with the following in the proxy-list:

ssl-server 1 cipher all-cipher-suites 81

You alternate port content rule can be used with a form of session persistence as well, ie. cookie, ARPT cookie, sticky-scrip, etc.

Hope this info clarifies everything!

- Jason

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
jason.espino Thu, 10/01/2009 - 18:11

Creating a redirect service on your CSS should accomplish what you are requesting. Simply create and apply the redirect service to the HTTP port 80 content rule on the CSS.

There is 2 different ways of doing a redirect service on the CSS. Use either a "redirect-string" or "domain". Both of which operate differently. If you want the CSS to preserve the client's path information within the initial URL request but redirect their connection to HTTPS then a type redirect service with "domain" would suffice.

Example of a "domain" redirect service configuration:

service redirect-https

type redirect

no prepend-http

keepalive type none

domain "https://www.domain.com"

active

How the "domain" redirect will operate:

Client types the following URL:

http://www.domain.com/admin

CSS performs a 302 redirect and sends the client to the following URL:

https://www.domain.com/admin

If you do not want the CSS to preserve the path information within the client's URL and simply redirect their connection to HTTPS then a type redirect service with "redirect-string" would be your option.

Example of a "redirect-string" redirect service configuration:

service redirect-https

type redirect

no prepend-http

keepalive type none

redirect-string "https://www.domain.com"

active

Customer types the following URL:

http://www.domain.com/admin

CSS performs a 302 redirect and sends the client to the following URL:

https://www.domain.com/

The client's connection should remain on HTTPS unless your webservers are setup to redirect the client's connection back to HTTP when they click specific URLs/links within the site. If that is the case then you can setup a urlrewrite rule on the proxy-list to ignore any 300 series redirects given off by the webservers. The CSS will rewrite the domain to HTTPS rather then HTTP when the servers "attempt" to redirect the client's connection back to HTTP.

The following rewrite rule will ignore ALL 300 series redirects given off by the Webservers:

ssl-server 1 urlrewrite 1 *

The following rewrite rule will ignore ALL 300 series redirects given off by the Webservers for the URL "www.domain.com":

ssl-server 1 urlrewrite 1 www.domain.com

Hope this info helps!

- Jason

sivaprakasam Thu, 10/01/2009 - 18:16

Hi,

There are 2 ways to implement this,

1.Create a service with Type Redirect and add the service to the content rule under the owner for the HTTP port as below,

service redir-https

keepalive type none

ip add 192.168.1.1

type redirect

no prepend-http

domain https://www.domain.com

active

owner domain

content http

vip address " 1.1.1.1"

protocol tcp

port 80

url "/*"

add service redir-https

active

2. The other way is to add the redirect URL directly in the content rule

owner Domain

content http

port 80

protocol tcp

vip address 1.1.1.1

url "/*"

redirect "https://www.domain.com"

active

The difference is that in the Service method only the domain portion of the URL is changed, the rest of the URL that has for example /abc/def.jsp is preserved.

In the Content Rule Method, the entire URL will be substituted with whatever is configured in the Redirect String.

Hope this answers your question.

Cheers

Siva Srinivasan

HP Enterprise Services

Great information from both answers, thanks a bunch.

I'd like to use the service type of redirect so as to preserve the URL, but the delima is how will that work with the SSL termination on the device?

The examples shown by the Cisco doc on the service redirect show that the IP address given in that service is a bogus one. Is that right?

Would this work?

service ssl_module

add ssl-proxy-list ssl-list1

keepalive type none

type ssl-accel

slot 2

active

service redir-https

keepalive type none

ip address

type redirect

no prepend-http

domain https://www.domain.com

active

owner domain

content http

vip address

port 80

protocol tcp

url "/*"

add service redir-https

active

content ssl

vip address

protocol tcp

port 443

add service ssl_module

active

Correct Answer
jason.espino Thu, 10/01/2009 - 20:12

You are correct. The IP address is bogus on the example you have provided. Your redirect service does not require an IP address in order for it to work properly.

The configuration you have posted should accomplish what you are requesting however you will need to add a new content rule:

service ssl_module

add ssl-proxy-list ssl-list1

keepalive type none

type ssl-accel

slot 2

active

service redir-https

keepalive type none

type redirect

no prepend-http

domain https://www.domain.com

active

owner domain

content http

vip address

port 80

protocol tcp

url "/*"

add service redir-https

active

content http

vip address

port 81

protocol tcp

url "/*"

add service web-service

active

content ssl

vip address

protocol tcp

port 443

add service ssl_module

advanced-balance ssl (if you want to maintain stickyness for SIDs)

application ssl (Reuse of SIDs for HTTPS connections)

active

The reason for the alternate port content rule(I just chose port 81, but any port can be used) is to allow the decrypted HTTPS connection/traffic to be handled to the webserver for processing. If you do not have the alternate port your HTTP connection will fall into a redirect loop if you have the proxy-list configuration setup to forward the decrypted traffic back to port 80. This pattern will continue and the browser will never be able to resolve content.

Redirect loop will occur with the following:

ssl-server 1 cipher all-cipher-suites 80

Content will be displayed correctly as the CSS can forward the decrypted traffic to an alternate port content rule for the webserver to process the connection with the following in the proxy-list:

ssl-server 1 cipher all-cipher-suites 81

You alternate port content rule can be used with a form of session persistence as well, ie. cookie, ARPT cookie, sticky-scrip, etc.

Hope this info clarifies everything!

- Jason

jason.espino Thu, 10/01/2009 - 21:05

Yes, your understanding of the communication process is correct. The HTTP port 80 content rule will redirect the client's connection; then the port 81 content rule would be used to process/handle the decrypted traffic from the client's HTTPS connection using the webserver.

Yes, you are also correct that the server must be configured to listen on the alternate port (this case 81) to correctly handle the client's traffic.

- Jason

Actions

This Discussion