O aplicativo Request Routing utiliza sessões SSL ao se conectar a servidores de conteúdo?

Question

No cenário em que o ARR está configurado para usar SSL / TLS para conectar-se aos servidores de conteúdo, ele utiliza sessões SSL (por exemplo, identificadores de sessão , conforme especificado em RFC 5246 ) para que conexões subseqüentes com os servidores de conteúdo possam utilizar um aperto de mão abreviado?

Em caso afirmativo, vários clientes podem ser atendidos usando uma única sessão SSL com o servidor de conteúdo?

Eu sei que a implementação SSL para ARR vem do componente schannel subjacente, e acredito que ele faça cache por padrão para ambos os lados da conexão por Como configurar o servidor Secure Sockets Layer e os elementos de cache do cliente . No entanto, não consegui encontrar um artigo definitivo para apoiar o cenário de ARR.

    

Answer 1

Respondendo a minha própria pergunta depois de usar o Wireshark para determinar a resposta.

Sim, o AAR utilizará sessões SSL e essas sessões poderão atender a vários clientes.

Usando o Wireshark, observei o seguinte:

Client1 -> AAR          GET /foo

AAR -> ContentServer    Client Hello
ContentServer -> AAR    Server Hello, Certificate, Server Hello Done
AAR -> ContentServer    Client Key Exchange, Change Cipher Spec, 
                        Encrypted Handshake Message
ContentServer -> AAR    Change Cipher Spec, Encrypted Handshake Message
AAR -> ContentServer    <encrypted application data>

Client2 -> AAR          GET /bar

AAR -> ContentServer    Client Hello
ContentServer -> AAR    Server Hello, Change Cipher Spec, 
                        Encrypted Handshake Message
AAR -> ContentServer    Change Cipher Spec, Encrypted Handshake Message
AAR -> ContentServer    <encrypted application data>

Isso se alinha exatamente com os resultados esperados mostrados nos diagramas em Aceleração SSL: habilitando a reutilização de sessão .

    

Answer 2

Primeiro de tudo, eu não sei a resposta, mas acredito que pelo menos use id de sessão.

Em segundo lugar eu iria descobrir não olhando documentação que pode ou não ser confiável em tal detalhe, mas cheirando o tráfego e de forma a garantir uma resposta 100% correta. Eu acho isso a maneira mais fácil quando se trata de proxies que podem manipular o tráfego para diferentes efeitos - ele realmente faz o que eu acredito que faz?

Se eu me lembro dos meus 'sniffings' corretamente, o SessionID é parte do cabeçalho do pacote SSL não criptografado e pode ser visto no Wireshark ou qualquer outro analisador de pacotes logo de cara.

Por fim, se você quiser descriptografar para obter uma visão completa que também é possível , e aqui também , para responder a sua segunda pergunta não através de dedução, mas através de dados de fluxo explícito.