Introduction
This article discusses how to secure content delivery from CDS Internet Streamer towards the end-user, with HTTPS. The user starts by sending the request over HTTPS towards the Service Router (SR). This request will get redirected, over HTTPS, and will eventually open a session with a streamer, over HTTPS. Because the CDS-IS don't support SSL offloading, we will use an ACE to offload SSL and present plain HTTP traffic to both the service router and the streamers. This can be combined with SR loadbalancing. Private key and certificate will be uploaded on ACE, in order to decrypt SSL. This delivery method is suitable for any content to be delivered over HTTP.
Network Diagram
Traffic Flow
1. Client requests the content over https, e.g. https://ds1.cds.xyz.com/video1.m3u8 and sends DNS query to D-Proxy
2. D-Proxy returns A record pointing to VIP on ACE
3. Client sends HTTPS request to ACE VIP
4. ACE decrypts SSL and sends plain HTTP request to SR
5. SR issues 302 redirection to client
6. ACE rewrite "Location" header from http to https, re-encrypt the response from SR and forward to client via https
7. Client open new session to Streamer (destination IP is real streamer IP)
8. ACE is on the path between client and streamer and receives the request. ACE offload SSL and forward the request to streamer over HTTP
9. Streamer serves client (HTTP)
10. ACE re-encrypt and forwards to client
Service Router
This section discusses the setup between client and Service Router.
DNS
The D-Proxy resolves ds1.cds.xyz.com to the ACE VIP 10.48.68.5
ACE
The client will send an https request like https://ds1.cds.company.com/video1.m3u8 to ACE VIP. ACE will offload the SSL and forward plain HTTP to SR. ACE will parse the 302 Redirect and rewrite it, as the router will issue a Location header of this type: Location: http://se1.se.ds1.cds.xyz.com/video1.m3u8 and needs to be rewriten to Location: https://se1.se.ds1.cds.xyz.com/video1.m3u8
ACE Configuration
// this is the action-list that will be applied in a policy in order to match any "Location" header that as an http:// URL and resplace by https://
action-list type modify http SSL_URL_REWRITE
header rewrite response Location header-value "http://(.*)" replace "https://%1"
//the service router
rserver host LB-SR1
ip address 10.1.22.4
inservice
// the ssl-proxy that will allow decrypting SSL, for that we ahd uploaded a private key and cert. In this case we use a self-signed certificate for demo purpose.
ssl-proxy service HTTPS_CDS
key mbr_priv.pem
cert mbr_cert.pem
//the serverfarm with one SR. There could be more than one if we would like to loadbalance.
serverfarm host CDE-SR
rserver LB-SR1 80
inservice
// the vip that the DNS resolves to and that the client initially tries to access
class-map match-all VIP_SR
2 match virtual-address 10.48.68.5 tcp eq https
//class binding the serverfarma and calling the Location header rewrite
policy-map type loadbalance first-match HTTPS_SR
class class-default
serverfarm CDE-SR
action SSL_URL_REWRITE
// the policy that will be applied to client facing interface. we call the ssl-proxy here in order to offload SSL.
policy-map multi-match GENERIC
class VIP_SR
loadbalance vip inservice
loadbalance policy HTTPS_SR
ssl-proxy server HTTPS_CDS
// in our example, vlan 120 is the vlan facing the client
interface vlan 120
ip address 10.1.20.11 255.255.255.0
service-policy input GENERIC
no shutdown
Streamers
The above sections showed how to have the initial redirection working. We have now the client requesting https://se1.se.ds1.cds.xyz.com.video1.m3u8
Flow
This is a little bit different here as we do not use a VIP on ACE. The traffic will route through the ACE, either "naturally", or via policy-routing.
Hence, when the request will hit the ACE, it will have a source IP address of the client, and a destination IP of the streamer. This is due to the fact that the SR already points the redirection to one particular CDE, "se1" in our example.
ACE Configuration
// the real server in this case is not a CDE but the next-hop towards the CDE
rserver host MSFC_33
ip address 33.33.33.1
inservice
// same as with SR
ssl-proxy service HTTPS_CDS
key mbr_priv.pem
cert mbr_cert.pem
// serverfarm containing the next-hop. 'transaparent' keyword means to send the forward the request towards CDE without changing destination IP.
serverfarm host MSFC
transparent
rserver MSFC_33 80
inservice
// no vip but a catch-all rule that will match any destination IP on tcp 443
class-map match-all TRANSPARENT_VIP_CDE
4 match virtual-address 0.0.0.0 0.0.0.0 tcp eq https
// same as with SR
policy-map type loadbalance first-match TRANSPARENT_LB
class class-default
serverfarm MSFC
// same as with SR
policy-map multi-match GENERIC
class TRANSPARENT_VIP_CDE
loadbalance vip inservice
loadbalance policy TRANSPARENT_LB
ssl-proxy server HTTPS_CDS
// in our example, vlan 130 is facing the client. Traffic towards streamers arrive here either via normal routing or policy-based routing.
interface vlan 130
ip address 10.1.30.11 255.255.255.0
service-policy input GENERIC
no shutdown
Related Information
Cisco Internet Streamer CDS 2.5 Software Configuration Guide
