4 ms·

Does anyone know how they "shut down https"?

• gsa 15y ago
  Probably means port 443 is blocked.
  • nathan_f77 15y ago
    Way more sophisticated than that. See http://news.ycombinator.com/item?id=3575269 http://news.ycombinator.com/item?id=3575269
• Wilya 15y ago
  I guess they block all SSL connections, or all least all those targetting unknown (non governement-approved) hosts.
• emilsedgh 15y ago
  They drop all encrypted connections. This means no https, no IMAP over TLS and no SSH connections. (Im in Iran)
  • haakon 15y ago
    Is it just by port, or do they detect SSL traffic at any port, and then block it?
    • emilsedgh 15y ago
      They have packet inspection and detect encrypted traffic on any port.
  • Simon_M 15y ago
    Is their filtering on a per TCP port basis? Or more advanced packet inspection?
  • Jach 15y ago
    How do they distinguish an encrypted connection from a non-encrypted connection? How do they know those indecipherable bits are an encrypted message vs. a part of an image or video? I suspect they just block domains and IPs and common ports or they sniff for common handshakes and key exchanges and kill those.
    • rplnt 15y ago
      Headers are encrypted too. Easy to decide I guess.
    • emilsedgh 15y ago
      It works at different levels. First, they try to drop the connection during handshake (which is NOT encrypted yet). This works effectively. SSH has been taken down using this technique for a few months. They also shape the bandwidth of encrypted connections. My guess is that they use something like L7 to guess the type-of-connection using different patterns.
  • rplnt 15y ago
    So where would one find SSL over http implementation? You know, you send your usual POST to a proxy, only the body would be an actual request. Whole handshake could probably be done like this. Not even the proxy would (wouldn't have to) know the content. Encrypted body could be translated to valid XML for extra effect.
    • Jach 15y ago
      I was just googling this and it looks like http://www.nocrew.org/software/httptunnel.html http://www.nocrew.org/software/httptunnel.html could handle that use case. (Another interesting idea I saw was to steg the data in cat pictures sent normally. I'm not sure if cat pictures are as big in Iran as in the US though such that even user-level analysis wouldn't be too suspicious if there's a ton of cats.)
      • drostie 15y ago
        I see three problems. The first one is that the Iranians would have to have their own JPEG images to sit in an "uploads" directory on the client, since what you're proposing is a very broad-scale steganography attack. (Or else we'd need a procedural way to generate a great number of images which look indistinguishable from real traffic that you might want to send. In any case we risk that the censors block image uploads and form POSTs.) Second is, I'm not sure anyone has yet connected steganography with public-key cryptography, but it really does have to be done that way for plausible deniability, otherwise you can just look inside the packets. So, inside the first JPEG linked from index.html there is steganographically hidden a 2048-bit RSA public key, and communication consists of uploading steganographic requests of the form encrypt(public_key, shared_key) | encrypt(shared_key, request). The first segment, the server knows should be 2048 bits = 256 bytes long. My bsencode project (https://github.com/drostie/bsencode https://github.com/drostie/bsencode) might be useful for formatting the data-to-be-encrypted; you need to transmit something like 32 bytes for a key, 16 bytes for a nonce, 32 bytes of predictable plain text so that the server knows that the request is intentional, perhaps 16 bytes of unrelated randomness just to give the RSA packet some extra entropy, and perhaps we could already specify some aspects of the protocol and intended query in the header as well. The 256 bytes would be plenty to contain an entire handshake. However, you would have to think long and hard about how the public key is encoded, since it's a two-part data structure and either part -- or the glue -- could "leak" the fact to an adversary able to do basic data-processing that there is an RSA key hiding in plain sight. Also the access pattern might leak this info -- how many places do you know which are important enough that Iranian citizens should have access to them, but follow a predictable pattern of "download HTML, download image, upload image"? The last part is the unique part; uploading images and lots of text is relatively uncommon. The third problem that I see is the interaction problem: Iran can guess at steganography by its access pattern, lots of large HTTP uploads followed by HTTP downloads -- but it can then confirm the guess by sending its own requests to the same server and validating that it gets valid responses back. So you can target the system by simply trying to use it. This last problem is much harder, I think. One obvious solution is to only handle one client at a time -- but that is dangerous because it paves the way for denial of service attacks from the government; they just take download of index.html followed by a GET request for a JPEG and try to send their own steganographic request, tying that server up with respect to real traffic. Mounting a good steganographic attack against the people who run the communications infrastructure is going to be very difficult indeed.
  • caf 15y ago
    So it sounds like you need a tool that adds low-entropy content to encrypted traffic to make it appear as if it's unencrypted? What unencrypted protocols are allowed / common?
  • deleted 15y ago
    [deleted]
• mrud 15y ago
  Typically Deep packet inspection. http://www.youtube.com/watch?v=DX46Qv_b7F4 http://www.youtube.com/watch?v=DX46Qv_b7F4 covers techniques different governments are using and the countermeasures deployed by tor