3 ms·
Sending a known source text using encryption isn't usually a good idea if you want to keep the key secret.
by rjsw 12y ago
Sending a known source text using encryption isn't usually a good idea if you want to keep the key secret.
- djcapelis 12y agoIf it were that easy to get keys HTTPS would be fucked.
- nitrogen 12y agoHTTPS uses a new key for every session.
- dogma1138 12y agoMost web servers out there implement one form of another of key reuse usually via a dedicated SSL Session Cache otherwise their CPU's would melt ;) One of the main reasons that SSL is relatively cheap right now is that not only you have some level of hardware acceleration, but web servers are now every good at managing and reusing SSL sessions. On NGINX the default TTL for an SSL session is 5min without constant keep alive, however on most installations that I've seen this has been extended significantly. You can store about 4000 sessions in 1 MB of data, that vs the amount of CPU cycles a handshake will take is a no brainier for most server owners. You can however configure your clients not to reuse an existing session, not sure how well servers will behave in that scenario, some servers which implement TLS actually use that feature as a security measure. mod_tls by default iirc only accepts SSL data sessiona with the same key as the SSL control session while the SSL session is in cache which makes some clients (old curl for example) actually incompatible with it so you might have issues when you trying to pull a file from an HTTPS or FTPS/SFTP service.
- e12e 12y agoReusing the session key implies that the client already knows the shared secret. Sure, if a client goes through his work-place, ssl-stripping proxy, then you might see that minitor@proxy.nsa.gov retrieved documentX, and that drone@proxy.nsa.gov retrieved the same document with the same session - but the traffic would be different unless all response headers were the same. And the proxy could just log the access anyway.