Is HTTPS POST by "network.request()" secure? (no one can see the content via packet sniffer?)

Solar2D General Questions/Discussion
#1

I am trying to make a HTTPS request by following sample code:

local body = "parameter=sensitive\_data" local params = {} params.body = body network.request("https://hostname/process\_sensitive\_data.php", "POST", networkListener, params)

Are the parameters in the body secure (no one can know the content via network packet sniffer)?

And when the response comes back, is the response also secure?

#2

Good a question, upvote to make it noticeable

#3

If your server is using SSL then yes as HTTPS runs on a different transport layer and everything above that layer is encrypted but if you are concerned about security I wouldn’t take anyones advice here as a true/false (it does or doesn’t) I would simply hook up shark or something and make the connection and see if everything is encrypted myself. :slight_smile:

#4

I had that same doubt and made a practical test. I installed a sniffer of my computer and tested http versus httpS. 

So, the BODY is indeed encrypted in a HTTPS connection (but the any param passed via GET is not). Therefore, you should not have a man-in-the-middle attack with that.

But, if the source (or destination) of the connection is compromised, the hacker can bypass the encryption and read the data directly from the it. 

#5

Thanks for the helpful info.

What do you mean “if the source (or destination) of the connection is compromised”?

#6

If the sender or receiver of the info is already hacked… e.g, if the sender is with some kind of trojan or worm that reads the info before it is being encrypted, the HTTPS will not be of so much value…

#7

When using HTTPS, the communication is encrypted end-to-end, both the request and the response. This includes the request URL and any GET parameters. The only thing in cleartext is the IP / hostname of the server and the port, since that information is necessary to route the packets.

#8

This was not what my practical test showed @_memo.  The URL and Get params are not encrypted.

UPDATE: I looked around it appears that @_memo is right about the url / get params. I don’t know if I was able to see the URL / GET params because my sniffer was the same computer send the info or because I was simply mistaken. Nonetheless, using GET creates other security holes that POST solves. So, use POST :slight_smile:

Source: http://security.stackexchange.com/questions/12531/ssl-with-get-and-post

#9

Good a question, upvote to make it noticeable

#10

If your server is using SSL then yes as HTTPS runs on a different transport layer and everything above that layer is encrypted but if you are concerned about security I wouldn’t take anyones advice here as a true/false (it does or doesn’t) I would simply hook up shark or something and make the connection and see if everything is encrypted myself. :slight_smile:

#11

I had that same doubt and made a practical test. I installed a sniffer of my computer and tested http versus httpS. 

So, the BODY is indeed encrypted in a HTTPS connection (but the any param passed via GET is not). Therefore, you should not have a man-in-the-middle attack with that.

But, if the source (or destination) of the connection is compromised, the hacker can bypass the encryption and read the data directly from the it. 

#12

Thanks for the helpful info.

What do you mean “if the source (or destination) of the connection is compromised”?

#13

If the sender or receiver of the info is already hacked… e.g, if the sender is with some kind of trojan or worm that reads the info before it is being encrypted, the HTTPS will not be of so much value…

#14

When using HTTPS, the communication is encrypted end-to-end, both the request and the response. This includes the request URL and any GET parameters. The only thing in cleartext is the IP / hostname of the server and the port, since that information is necessary to route the packets.

#15

This was not what my practical test showed @_memo.  The URL and Get params are not encrypted.

UPDATE: I looked around it appears that @_memo is right about the url / get params. I don’t know if I was able to see the URL / GET params because my sniffer was the same computer send the info or because I was simply mistaken. Nonetheless, using GET creates other security holes that POST solves. So, use POST :slight_smile:

Source: http://security.stackexchange.com/questions/12531/ssl-with-get-and-post