I was asked to explain exactly what happens in the “Transparent Secure Channel” as described in the “Cisco Wide Area Application Services SSL Application Optimizer Deployment Guide“. Here is the section under discussion – I’ve highlighted in red the point I want to concentrate on.

[Note, this post assumes a familiarity with the operation of Cisco WAAS – if you are not familiar with Cisco WAAS I can recommend some great training sessions]

Cisco WAAS is an industry-leading, comprehensive WAN optimization and application acceleration solution. It now includes SSL optimization features that integrate transparently into the existing PKI trust model in customer deployments and can be easily deployed without compromising the existing data center key management security.
With Cisco WAAS, the SSL trusted model is maintained in the data center. Server private keys are stored securely on the core Cisco WAE and WAAS Central Manager and never leave the security of the data center. The temporary SSL session keys are distributed from the secure core Cisco WAEs to the edge Cisco WAEs over a secure HTTPS connection between an edge Cisco WAE and a core Cisco WAE. In addition, the Cisco WAAS SSL Application Optimizer operates in a transparent mode that does not require any changes to either the client or the server participating in the SSL connection. Figure 1 shows how Cisco WAAS SSL optimization integrates transparently into existing application key exchanges and preserves the trust boundaries of server private keys.
• During the initial client SSL handshake, the core Cisco WAE in the data center participates in the conversation. The connection between the Cisco WAEs is established securely using the Cisco WAE device certificates, and the Cisco WAEs cross-authenticate each other.
• After the client SSL handshake is complete and the data center Cisco WAE has the session key, the data center Cisco WAE transmits the session key (which is temporary) over its secure link to the edge Cisco WAE so that the edge Cisco WAE can start decrypting the client transmissions and apply DRE.
• The optimized traffic is then reencrypted using the Cisco WAE peer session key and transmitted, in-band, over the current connection, maintaining full transparency, to the core Cisco WAE in the data center.
• The core Cisco WAE then decrypts the optimized traffic, reassembles the original messages, and reencrypts the traffic using a separate session key negotiated between the server and the data center Cisco WAE.
• If the back-end SSL server requests that the client submit an SSL certificate, the core Cisco WAE requests one from the client. The core Cisco WAE authenticates the client by verifying the SSL certificate using a trusted CA or an Online Certificate Status Protocol (OCSP) responder.

Figure 1 (From http://www.cisco.com/en/US/prod/collateral/contnetw/ps5680/ps6870/deployment_guide_c07-541981.html#wp9000151)

This is how it goes (at least, this is how I BELIEVE it goes – if anyone has more detail, I’d love to know)

To keep the discussion simple, I’ll name the main objects in the scenario as shown in (Figure 1) A, B, C & D:
A=client PC
B=client side WAE
C=server side WAE
D=server

What you have to remember is that there is a proxy operation going on between the two WAEs.

So (As usual, I’ll start at the beginning- SIP=Source IP Address, DIP=Destination IP Address):
A sends the initial SYN  SIP=A, DIP=D
B marks it with 0x21   SIP=A, DIP=D
C notes a half connection – but also realises that this is a SYN for an SSL session so proxies the session.  In other words it acts as a “man-in-the-middle”
D receives the SYN+opt0x21 SIP=A, DIP=D
D replies with SYN+ACK   SIP=D, DIP=A
C marks it with 0x21    SIP=D, DIP=A
B recognises this as the reply to an SSL initiation
A receives the SYN+ACK SIP=D, DIP=A
The final ACK of the TCP handshake is sent and seen by all SIP=A, DIP=D
A begins the SSL Session to D SIP=A, DIP=D
C intercepts this session, and masquerades as D to send replies to A    SIP=D, DIP=A
At the same time, C begins a “masqueraded” SSL Session to D, pretending to be A SIP=A, DIP=D
At the end of the SSL handshaking, C holds the keys to two SSL sessions that appear to be between A & D.  At this stage, one of these sessions is in reality between A & C, while the other is between C & D

Here’s the clincher:
C starts sending packets “over its secure link to the edge Cisco WAE ” (as the article says).  In other words, C starts sending packets to B that are labelled as SIP=D, DIP=A

B replies with packets that are marked as SIP=A, DIP=D but are really from B to C – presumably there is some kind of key exchange to be able to encrypt the session key securely.

Related articles

• Cisco WAAS Case Study Worth Posting a Blog (blogs.cisco.com)
• HTTPS Communication: How it works? (singztechmusings.wordpress.com)