5 ms·

> And occurring or believed likely to occur in a different cipher or code message Does anyone know if TLS/HTTPS does padding or tries to alter the length of ci

> And occurring or believed likely to occur in a different cipher or code message Does anyone know if TLS/HTTPS does padding or tries to alter the length of ciphertext? I ask because a specific length for a specific request that is known to be a certain Wikipedia page (for example: https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_Levant https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_...) means certain encrypted request's plaintext are known to an adversary. Is each encrypted network request's ciphertext different or padded to a new size?

maqp 5y ago
AFAIK TLS doesn't make such attempts simply because that would make it quite inefficient. However, if you're using Tor (like you probably should if you want privacy for online browsing) the exit-node that fetches the site for you gets the leaky packet size, and the Tor cell -packets that transit from the exit node to you are static size (500 bytes IIRC). The number of packets can of course be quite revealing too, but all simultaneous data transfer over Tor adds noise to end-to-end correlation on your end.
beermonster 5y ago
PCKS#7 padding IIRC
jdjgktntnrk 5y ago
This is a classic problem (traffic analysis) that in principle can only be solved by having the browser access random wikipedia pages in a continuous manner, to create cover traffic.
mrmckizzle 5y ago
I'm no expert in cryptography, but don't most versions of TLS/HTTPS use RSA for encryption? Which in turn uses the private/public key methodology to prevent such attacks?
- throwaway525142 5y ago
  No AFAIK. The actual traffic is encrypted using a block cipher. Asymmetric crypto is only there to verify each peer's identity and establish a common secret for the symmetric cipher.
  - joppy 5y ago
    This is right - asymmetric crypto is awesome but just not anywhere near as fast as something like AES for chewing through chunks of data. So some anonymous asymmetric crypto (Diffie-Hellman or similar) is used to set up an encrypted channel, i.e set up a shared AES key, and then RSA is used to verify that the entity on the other end actually holds the private key for that subdomain. After that it’s AES pretty much all the way.
  - beermonster 5y ago
    Yup that’s basically how it works. Usually when PFS is involved the keys are session based as opposed to using the same keypair for every session. This mitigates passive monitoring and future private key compromise/legal pressure permitting historic decryption of sniffed TLS sessions.
- beermonster 5y ago
  They use a form of key exchange (using RSA, Diffie-Hellman etc) to transfer the (symmetric) key used by the symmetric block cipher. So typically ECDHE and AES-256-GCM for e.g. so the symmetric key is wrapped.
- wolf550e 5y ago
  Even in the 90s, SSL (and PGP) used hybrid encryption. The data is encrypted (and authenticated) using symmetric primitives and the symmetric keys are exchanged or established using asymmetric cryptography. Asymmetric cryptography is also used to authenticate the counter party. RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated. These days RSA is only used in digital signatures (which are not encryption) while key exchange is done using Diffie Hellman (specifically ECDHE). CBC mode cipher suites used to add up to 8 bytes of padding (for deprecated 3DES) and up to 16 bytes of padding for AES, but the mac-then-encrypt TLS construction turned out to be very hard to implement correctly, so TLS 1.3 only allows modes based on CTR (AES GCM, CCM and ChaCha20-Poly1305) so not even minimal padding is done.
  - SAI_Peregrinus 5y ago
    > RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated. s/does/doesn't/ there.
  - maqp 5y ago
    "These days RSA is only used in digital signatures (which are not encryption)" AFAIK digital signatures are created by encrypting the hash of the plaintext (be it content ofthe certificate or a message or whatnot). But yeah, RSA isn't really used for key exchanges due to it lacking forward secrecy. There are exceptions to this unfortunately, such as Apple's iMessage which is decades behind in cryptographic innovation.
    - wolf550e 5y ago
      Please don't repeat terrible 90s pedagogy about RSA. Even in RSA, the padding for signatures and for encryption is different (for very important reasons). The fact that RSA encryption and RSA signatures share code (but are not identical) is just a quirk of RSA that instead of making the thing simpler to explain made it harder to explain well - people think this generalizes and try to understand where is the encryption in Ed25519 or whatever and are very confused. If you want to point out the difference between "public key operation" (encrypt, verify) and "private key operation" (decrypt, sign), use those terms. That makes sense and the distinction is important. People end up with basically misinformation in their heads and other people on stackoverflow (and IRL) spend lots of time trying to sort them out. You just made the problem a little worse. Please don't do that. Here is an actual cryptographer explaining: https://security.stackexchange.com/a/87373/70830 https://security.stackexchange.com/a/87373/70830
espadrine 5y ago
> a specific length for a specific request that is known to be a certain Wikipedia page (for example: https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_ https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_...) means certain encrypted requests are known to an adversary. While you are right in principle (generally: all encryption schemes explicitly exclude message length from their confidentiality claims), in practice, some parts are user-specific (such as the username if you are logged in, and which compression algorithm is selected). That said, the ideal encryption tunnel is one which is always running, transmitting a random stream that is likely encrypting a sequence of zeroes most of the time. The energy consumption may be problematic however.
nmadden 5y ago
Older CBC cipher suites padded to the next multiple of 16 bytes (for AES). TLS 1.3 doesn’t support these anymore but added a more general padding mechanism [1]. I don’t know whether any browser actually uses it though. [1]: https://datatracker.ietf.org/doc/html/rfc8446#section-5.4 https://datatracker.ietf.org/doc/html/rfc8446#section-5.4
uuidgen 5y ago
There is no such mechanism in TLS, but HTTP Range header and wikipedia supports it. So if you want to be protected agains this side-channel problem you can use Connection: Keep-Alive header along with Range header to split each request into a few Range requests. As TLS pads data to the block size you can introduce uncertainty of 0-8 bytes per chunk. Put some random delays between chunks and while it will be slower and with a bit higher overhead passive attacker won't tell if you're requesting one article in chunks or a few other. And all this can be implemented client-side.

maqp 5y ago

AFAIK TLS doesn't make such attempts simply because that would make it quite inefficient. However, if you're using Tor (like you probably should if you want privacy for online browsing) the exit-node that fetches the site for you gets the leaky packet size, and the Tor cell -packets that transit from the exit node to you are static size (500 bytes IIRC). The number of packets can of course be quite revealing too, but all simultaneous data transfer over Tor adds noise to end-to-end correlation on your end.

beermonster 5y ago

PCKS#7 padding IIRC

jdjgktntnrk 5y ago

This is a classic problem (traffic analysis) that in principle can only be solved by having the browser access random wikipedia pages in a continuous manner, to create cover traffic.

mrmckizzle 5y ago

I'm no expert in cryptography, but don't most versions of TLS/HTTPS use RSA for encryption? Which in turn uses the private/public key methodology to prevent such attacks?

throwaway525142 5y ago
No AFAIK. The actual traffic is encrypted using a block cipher. Asymmetric crypto is only there to verify each peer's identity and establish a common secret for the symmetric cipher.
- joppy 5y ago
  This is right - asymmetric crypto is awesome but just not anywhere near as fast as something like AES for chewing through chunks of data. So some anonymous asymmetric crypto (Diffie-Hellman or similar) is used to set up an encrypted channel, i.e set up a shared AES key, and then RSA is used to verify that the entity on the other end actually holds the private key for that subdomain. After that it’s AES pretty much all the way.
- beermonster 5y ago
  Yup that’s basically how it works. Usually when PFS is involved the keys are session based as opposed to using the same keypair for every session. This mitigates passive monitoring and future private key compromise/legal pressure permitting historic decryption of sniffed TLS sessions.
beermonster 5y ago
They use a form of key exchange (using RSA, Diffie-Hellman etc) to transfer the (symmetric) key used by the symmetric block cipher. So typically ECDHE and AES-256-GCM for e.g. so the symmetric key is wrapped.
wolf550e 5y ago
Even in the 90s, SSL (and PGP) used hybrid encryption. The data is encrypted (and authenticated) using symmetric primitives and the symmetric keys are exchanged or established using asymmetric cryptography. Asymmetric cryptography is also used to authenticate the counter party. RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated. These days RSA is only used in digital signatures (which are not encryption) while key exchange is done using Diffie Hellman (specifically ECDHE). CBC mode cipher suites used to add up to 8 bytes of padding (for deprecated 3DES) and up to 16 bytes of padding for AES, but the mac-then-encrypt TLS construction turned out to be very hard to implement correctly, so TLS 1.3 only allows modes based on CTR (AES GCM, CCM and ChaCha20-Poly1305) so not even minimal padding is done.
- SAI_Peregrinus 5y ago
  > RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated. s/does/doesn't/ there.
- maqp 5y ago
  "These days RSA is only used in digital signatures (which are not encryption)" AFAIK digital signatures are created by encrypting the hash of the plaintext (be it content ofthe certificate or a message or whatnot). But yeah, RSA isn't really used for key exchanges due to it lacking forward secrecy. There are exceptions to this unfortunately, such as Apple's iMessage which is decades behind in cryptographic innovation.
  - wolf550e 5y ago
    Please don't repeat terrible 90s pedagogy about RSA. Even in RSA, the padding for signatures and for encryption is different (for very important reasons). The fact that RSA encryption and RSA signatures share code (but are not identical) is just a quirk of RSA that instead of making the thing simpler to explain made it harder to explain well - people think this generalizes and try to understand where is the encryption in Ed25519 or whatever and are very confused. If you want to point out the difference between "public key operation" (encrypt, verify) and "private key operation" (decrypt, sign), use those terms. That makes sense and the distinction is important. People end up with basically misinformation in their heads and other people on stackoverflow (and IRL) spend lots of time trying to sort them out. You just made the problem a little worse. Please don't do that. Here is an actual cryptographer explaining: https://security.stackexchange.com/a/87373/70830 https://security.stackexchange.com/a/87373/70830

espadrine 5y ago

> a specific length for a specific request that is known to be a certain Wikipedia page (for example: https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_ https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_...) means certain encrypted requests are known to an adversary. While you are right in principle (generally: all encryption schemes explicitly exclude message length from their confidentiality claims), in practice, some parts are user-specific (such as the username if you are logged in, and which compression algorithm is selected). That said, the ideal encryption tunnel is one which is always running, transmitting a random stream that is likely encrypting a sequence of zeroes most of the time. The energy consumption may be problematic however.

nmadden 5y ago

Older CBC cipher suites padded to the next multiple of 16 bytes (for AES). TLS 1.3 doesn’t support these anymore but added a more general padding mechanism [1]. I don’t know whether any browser actually uses it though. [1]: https://datatracker.ietf.org/doc/html/rfc8446#section-5.4 https://datatracker.ietf.org/doc/html/rfc8446#section-5.4

uuidgen 5y ago

There is no such mechanism in TLS, but HTTP Range header and wikipedia supports it. So if you want to be protected agains this side-channel problem you can use Connection: Keep-Alive header along with Range header to split each request into a few Range requests. As TLS pads data to the block size you can introduce uncertainty of 0-8 bytes per chunk. Put some random delays between chunks and while it will be slower and with a bit higher overhead passive attacker won't tell if you're requesting one article in chunks or a few other. And all this can be implemented client-side.