Implement basic steganography in the proxy. #11
Comments
|
Hey Yashin, I can help on this issue. Jay |
|
I think a better idea would be to take the HTTP data and put it through two layers obfuscation, first by doing an encryption of the HTTP body through some form of public-key encryption. We can then hide this encrypted body in an image (thus it might be prudent to have a large repository of images) which we can then use the Imgur API to load onto imgur. The benign request or response would then just look like a simple Imgur HTTP response similar to:
We can include in the benign Imgur HTTP response a simple text key letting the other end no which image and decryption method to use to decrypt the Imgur image.
|
|
Thanks for the interest! I'll be uploading the code of the proxy server within a few hours. We can get started from there. And @boxtown : That sounds like a very good idea. Once we have the proxy code up we can get started on implementing it into the proxy. |
|
Hi Yashvin, I can chip in my contributions. |
|
We have a proxy server implemented that does only basic proxying. Modify the buffer mentioned at https://github.com/openfaux/openfaux-server/blob/master/server.py#L22 to modify the content that is being passed back to the client. So whatever server side steganography is to be implemented, it'll have to be implemented there. |
|
I've forked the repository and will have a basic demo algorithm by tonight |
|
@boxtown We're building towards a more secure browsing experience for users at the "local" level. We want to provide added security against man-in-the-middle attacks. Posting all of our users data (even if encrypted and hidden) on a third-party site where it's publicly available would take the danger from man-in-the-middle to all of the imgur user base. On top of the security risk, we'd also be relying on a third-party system, it would add a huge overhead in the time it takes to upload the image (an image would be significantly larger than pure text) then the user to download the image, it would also add a huge cost on startup since we'd have to have more powerful servers to manage the cost of this extra overhead with the images. All-in-all while it's a cool idea, and one we discussed before deciding on our current design, it's impractical for our purposes. |
|
I believe the security issue is the same regardless of if it's being uploaded to imgur or not because the risk is based on the man-in-the-middle knowing to look for an encrypted message hidden in the benign data whether it be an HTML response or an image file. I do empathize with the amount of overhead needed for an image vs. plaintext so I'll shift gears and work on text -> text stenography instead |
|
Need to halt on this in general right now. Was having a discussion about how to implement an encryption secret system (two separate ones actually, but this is why we have discussions) and came to the realization we get absolutely 0 benefit from steg. The reason being that it's known, once you know there's data hidden there steg loses all of it's benefit since it's not really encrypting anything itself (encryption is separate but can be incorporated into in a sense) just masking the data. We can still do everything we want to do, benign data and real data to allow the user to hide what they are browsing without suspiciously closing the browser at the press of a hot-key and so on. With text -> text steg you can just get the original benign data (the headers are still intact, required to render the HTML) then run the linux diff command on the data the user received and the original benign data and you get the output of the real data (encrypted of course) so it doesn't add anything and this can be applied to images away if you treat them as binary files instead of images, on top of that we're open source with a client plugin that will have the de-steg algorithm so they could just grab that code... I'm going to leave this ticket open until I've had a chance to better discuss this with Yashin, but as of now I can't see a benefit to this anymore. Luckily with a modular design it won't hurt us in the long run, just kinda disappointing that we can't come up with a use for it, seemed like it'd be fun. I'm always open to discussion and feed back so if anyone can think of some way to redeem steg or a flaw I missed, feel free to let me know. |
|
I personally am of the same mind as you. Steg is only useful if someone doesn't expect the hidden message to be there. Otherwise it adds almost nothing. |
|
There are always other neat services we're in a good position to implement, a couple of the top things I've been thinking about is allowing for optimizing pages before sending to the client. Such as on the server make the requests for any CSS/JS files then bundle them into the response to the client so the client doesn't have to make multiple calls for each of the files. Or a server-side adblocking system. This would be awesome for mobile since any client-side adblock still requires you to spend the data to get the ad, it's just blocked from displaying so it saves data for mobile, the only issue I can see here is if we start doing this we may get ourselves black listed from major ad driven sites. I still like the idea of using benign data then allowing uses a hot-key to swap between the real and fake data. |
ghost
assigned 
|
Hey all i have developed an encription metod with 0(n) complexity which can give an unconditionaly secure data.. |
|
Purpose of steganography is not to hide data but to hide the existance of data.So may be we should use encription methods for this |
|
The only problem I can see is that steganography into images is not instant. We should try to use relatively small images, that way they can be loaded very quickly. |
|
|
I meant the time it takes to load the image, and then to write the new image data to the file. The actual algorithm of hiding the data in the pixels is obviously negligible. |
|
@yentup @boxtown @sarathsp06 @arunenigma @julesbond007 @admwx7 We have decided to continue with our plan to implement steganography. @Sp3ctr3 said he has some ideas in regards to how we can do it and is working on the implementation currently. |
|
Awesome. |
|
@Sp3ctr3 Yashin, have you decided on any particular steganographic technique? |
|
The thing is we have a lot of benign material to work with in case of responses. We don't have as much in the case of requests. Anyone have any ideas? @arunenigma I'll look into spread sprectum. |
|
Just generate a large block of random data using something like the one pad cipher, encrypt the request body and any headers you want using something like AES and encrypt the AES key with RSA. Then just hide the encrypted AES key and body in the random data |
|
Hmm. I thought of something similar too. Where in the benign request would we store the random data if we are using stego? |
|
Just generate a generic POST request for some (possibly imaginary) service that requires a username and password or some for of authentication. Then in the request body we can just have a JSON object and we can fill in some random field(like a password field or an auth field) with the random data |
|
Sounds great. That should be enough for the request. I'll forward it to the client side programmers. |
|
The problem wid small image is smaller the image the smaller the data On 12/11/2013 12:02 AM, yentup wrote:
|
|
What's steganography meant to hide? Is it meant to route traffic to something other than your server? Because it sounds completely unnecessary, every modern site does TLS and that's what will be expected. Just adding TLS to your proxy sounds many, many times better than what you guys are proposing. |
|
It's meant to mask the requests and responses for the client. If an attacker were to sniff the connection he would observe a different request. Inside that benign request we would add our encrypted data via steganography. Here is a flowchart. |
|
Whom is it supposed to mask it from, and to which server? If it's to the proxy, an attacker already knows it's a proxied request to your service, and can't read it. I don't understand whom steganography is meant to hide requests from... |
|
The traffic is supposed to be masked from the viewpoint of an attacker listening between the client and the openfaux proxy. |
|
But TLS already does that, so what is the scenario where the attacker can break TLS and look at the actual data (and why not just fix that)? |
|
TLS doesn't mask the data/request, it's just an encryption layer. The point where that encryption is broken is what we're looking at expanding on, so once they break TLS instead of just seeing your data they will get a bunch of what looks like useless garbage thanks the steno magic. If they get past the steno then they would have to deal with an added layer of encryption. |
|
TLS masks the data and request because it's encryption. If someone can break TLS, they are very likely to be able to break whatever encryption you can implement on top of it very easily, so this sounds very risky. My advice would be to properly use TLS with pinned certificates on the client and not waste any time inventing your own steno/crypto. |
|
I agree that disregarding TLS is dangerous. We will implement TLS of course but we will also implement our encryption too. We are also using industry standard crypto such as AES and RSA. Defence in depth in a sense. |
|
Is there a specific TLS attack that your scheme will prevent? If so, how, and why doesn't TLS already implement it? |
|
Our service won't prevent TLS attacks. In case TLS connection, they will have to go through stego as well as an additional layer of encryption. |
|
Let me rephrase, what is the specific attack your encryption and steganography layers will prevent that TLS will not? I'm assuming there is one, because, if the additional encryption and steganography don't prevent any attacks, then they are unnecessary. |
|
Let's say an attacker is running sslstrip and tshark. The https connection becomes http and the user is not paying attention and has not installed HttpsEverywhere. The attacker will see the data that is being transferred between the client and the server but it will see the benign data first. If the attacker persists and discovers the hidden data, it is still encrypted. I hope that's the answer you are looking for. |
|
Well, if the attacker is running sslstrip, they have to have access to the user's machine so they can install an overriding certificate as well. If they do that, they might as well install a traffic/key logger there to capture everything, so you've already lost. Even assuming they break TLS like that, they can just go on and break your encryption as well. It sounds like you're planning to do a whole lot of work just to prevent a very dedicated attacker that was just lazy enough to not break the second layer. |
|
Access to the user's machine is not needed to run sslstrip. The attack is usually done by DNS or ARP spoofing. It's a network attack. And yes, a determined attacker could break our encryption too but we are making the attack more difficult. |
|
sslstrip can be defeated by using pinned certificates, and, since you control the client, that's no issue for you. Anyway, my opinion is that this is a bit of a waste of effort because the benefit is minimal. |
|
AFAIK certificate pinning won't mitigate sslstrip because it downgrades the connection to HTTP. Certificate pinning should only help AFTER the certificate has been obtained from the server. Correct mitigation to sslstrip would involve using HSTS and verifying the connection is secured at client side. |
|
AFAIK, sslstrip takes advantage of existing HTTP links to redirect to the attacker's fake-HTTPS server. Since you control the client, this doesn't matter to you, you can just bake the certificate fingerprint into the client before release. |
|
It doesn't just redirect to the fake HTTPS server. It either downgrades or changes it to a homograph-similar HTTPS address. In the latter hardcoded certificates would not work as it the link just looks similar to the human eye and is not in fact the same. |
|
Don't you control the client proxy, i.e. the client part of the client-server (your client, the local proxy, to your server, the remote proxy) connection? |
|
Yes we do. |
|
Then you can just hardcode the certificate fingerprint and refuse to connect if it's different. You can even use a self-signed certificate. |
|
Again, in a homograph similar attack the server side certificate will be valid. The hardcoded certificates will not be checked because the link looks similar to the link in the address bar but it is in fact a different link for which the client side does not have certificates. Also it will need us to have a local database of certificates. |
|
You're misunderstanding me, a homograph attack won't work here because it's not a person checking the URL bar of a browser, it's your client (a program) checking to see if it connected to the correct TLS host. If the fingerprint of that host's certificate is not what you have installed on your server yourself, it can refuse to connect. It doesn't matter if the certificate is valid or not (and that's why the certificate can be self-signed). |
|
How will the client distinguish whether the user wants to visit login.com and |ogin.com? If we add a hardcoded certificate for login.com but the user's traffic is sabotaged by sslstrip so that he is actually taken to |ogin.com (just an example), the client wouldn't have a certificate for that. It will have to accept whatever certificate the fake server provides. So my question is how will the client decide what the "correct TLS host" is? |
|
Is the discussion for the part between the openfaux client and the openfaux server, or between the browser and the end website (say example.com)? How are you going to fix the latter by any amount of encryption anyway? You'll have to decrypt the request at the openfaux server to send it along to example.com. |
|
The latter, or the openfaux case if we are depending just on TLS. We are decrypting the request at the openfaux server. It's partly implemented in the "enc" branch as well as detailed in the flowchart. As to "fixing" TLS, it doesn't. It's just one more layer of security on top of TLS. |
|
So it doesn't matter what happens with example.com, because the request goes out to it as usual, except it originates from the openfaux server rather than the user's computer. Therefore, the only thing worth discussing is the communication between the openfaux client and server, which is the place where you can hardcode the certificate fingerprint and avoid the entire second encryption layer. |
|
True |
Implement a basic form of steganography using the content manipulation done by the proxy. One suggestion is to hide the entire HTTP data in a div and then put it in a benign request or response.
The text was updated successfully, but these errors were encountered: