Your deployment guide understanding is correct. However you need to understand that HTTPS acceleration is only for Intranet servers = servers you own and which are close to the Server side Steelhead. It is not for Internet based servers. To accelerate some Internet traffic, you should check SteelHead SaaS. Also to achieve true benefit of acceleration, it is advisable to have sSH as close to servers as possible.
> - The HTTPS server might not be mine (for example https://www.riverbed.com) and the owner will not send me the server private key.
That is correct. Otherwise they would compromise their security.
> - It's not scalable, I shouldn't have to import every single certificate and private key of HTTPS servers I would like to optimise.
Actually it is quite scalable. For Intranet you can use wildcard certificates and for Internet traffic you can use above mentioned SaaS.
>I would have expected to work like this:
> - The sSH sets up a SSL channel with the HTTPS server and as long as the CA that signed that HTTPS server
> certificate is installed on the sSH it should be fine.
That part would work, but other part would not:
>- The sSH sets up a SSL channel with the end user using its certificate and as long as the CA that signed that
> sSH certificate is installed on the Client it should be fine.
This is completely flawed idea:
- First of all we are talking about HTTP/HTTPS - HTTP(S) is protocol where client initiates the connection, so for sSH to setup the connection you could be blocked by firewall or hit the NAT along the way so sSH would never reach client.
- Second reason - client normally does not have client-side certificate, so sSH would be not able to verify the client. Even if client had client-side certificate, it does not act as web-server so I don't think verification in oposite direction would work. On the other hand Client side certficate are more complex.
- You solution would most likely require some special software/server to be installed to all clients which Riverbed tries to avoid, their goal is that HTTPS acceleration is transparent to clients. At the same time they still ensure security between client and server which is normally a goal not easily achieved.
>Did some of you optimise SSL traffic and found another way without importing the HTTPS private key on the
> cSH ?
We optimize SSL and we have not found any other way. If there would be easier way, Riverbed would make it standard.
Just a last advice: If you find easy way of SSL acceleration, you will most likely compromise security, so I advise you not to even explore it unless you are security expert able to mathematically proof your solution.
Hello and thank you for your answer.
I have made progress since my first message and able to optimize HTTPS traffic as I wanted (at least it seems to).
What I do is that I generate a private key and certificate request with CN=www.riverbed.com (nb: SAN are not supported). Then I make it signed by my own CA and import the signed certificate and the private key on the Steelhead.
On the client side I import my own CA in the client CA store.
(You didn't understand what I meant because you think I wanted to do client authentication).
When the client goes to www.riverbed.com with https the connection is optimised but if he clicks on the lock to see how the certificate looks like, he will see that it's signed by my own CA.
That way, I'm able to optimize Internet traffic with asking their private keys.
-> I haven't tried the wildcard yet but that should be a good option.
You told about security and yes I have to pay attention to security on the sSH:
- Datastore encryption
- Secure Vault
And protect my CA key
And protect the clients so people should not be abled to push their own CA in their store.
...I think that's all, if you see something else don't hesitate to tell me.
-> The second thing I'd like to make it work is certificate chaining, when the client trusts only the root CA, but the certificate is signed by an intermediary CA.
For real I don't want to optimise Internet https traffic but only some specific traffic that comes from a partner. That's why I can't ask their private keys.
I have not checked Saas optimisation but I think it works only with specific partners for optimisation on Internet.
I'm coming back to close this topic.
Riversailor, I'm sorry but you're wrong in your approach and Riverbed is wrong to advice to ask for the servers' private keys.
The best way and scalable is documented in a specific document talking about proxy certificates, it should be however included in the deployment guide to avoid loss of time.
That's the way I talked about in my previous post.
I haven't still tested the certificate chaining but I will. The quick workaround is to import all the certificates in the clients' store certificates.
Thank you anyway, it's always nice to have someone participate in a technical topic and give new ideas and point of view.