2 copy edit; formatting; typos
source | link

There is no way to split the TLS handshake into three parts in the way you envision, i.e. that part of the handshake comethat comes from the original client, part offrom the "TLS bridging" service and part from the server.

One reason is that the FinishedFinished message from the client side can not be constructed in a way that the server will accept it: The FinishedFinished message needs both the master secret which and also a hash over all handshake messages. But since the master secret is only known to the original clientmaster secret is only known to the original client and all handshake message are only known to the TLS bridging servicehandshake message are only known to the TLS bridging service (since it has added messages to the handshake) neither the original client nor the TLS bridging service has all information needed to construct the FinishedFinished message.

All you could do is to create a full man in the middle proxy which results in a full TLS connection between client and bridging service and another one between bridging service and server. Of course the bridging service would then need to recreate the original serversserver's certificate by using its own CA and the client would need to trust the CA of the bridging service.

There is no way to split the TLS handshake in the way you envision, i.e. that part of the handshake come from the original client, part of the "TLS bridging" service and part from the server.

One reason is that the Finished message from the client side can not be constructed in a way that the server will accept it: The Finished message needs both the master secret which and also a hash over all handshake messages. But since the master secret is only known to the original client and all handshake message are only known to the TLS bridging service (since it has added messages to the handshake) neither the original client nor the TLS bridging service has all information needed to construct the Finished message.

All you could do is to create a full man in the middle proxy which results in a full TLS connection between client and bridging service and another one between bridging service and server. Of course the bridging service would then to recreate the original servers certificate by using its own CA and the client would need to trust the CA of the bridging service.

There is no way to split the TLS handshake into three parts in the way you envision, i.e. that part of the handshake that comes from the original client, part from the "TLS bridging" service and part from the server.

One reason is that the Finished message from the client side can not be constructed in a way that the server will accept it: The Finished message needs both the master secret and also a hash over all handshake messages. But since the master secret is only known to the original client and all handshake message are only known to the TLS bridging service (since it has added messages to the handshake) neither the original client nor the TLS bridging service has all information needed to construct the Finished message.

All you could do is create a full man in the middle proxy which results in a full TLS connection between client and bridging service and another one between bridging service and server. Of course the bridging service would then need to recreate the original server's certificate by using its own CA and the client would need to trust the CA of the bridging service.

1
source | link

There is no way to split the TLS handshake in the way you envision, i.e. that part of the handshake come from the original client, part of the "TLS bridging" service and part from the server.

One reason is that the Finished message from the client side can not be constructed in a way that the server will accept it: The Finished message needs both the master secret which and also a hash over all handshake messages. But since the master secret is only known to the original client and all handshake message are only known to the TLS bridging service (since it has added messages to the handshake) neither the original client nor the TLS bridging service has all information needed to construct the Finished message.

All you could do is to create a full man in the middle proxy which results in a full TLS connection between client and bridging service and another one between bridging service and server. Of course the bridging service would then to recreate the original servers certificate by using its own CA and the client would need to trust the CA of the bridging service.