Man in the middle attack: luasec / ssl encryption / https

Solar2D Network
#1

Hi All!

I am developing a business app that does REST calls on a remote server (this server is in my control). I keep an officially signed certificate on this server (to say clearly: it is NOT self signed).

As for security reasons I need to be sure that there is no man in the middle attack going on. This would be easily possible if the “man in the middle” would use a correctly issued and signed certificate. So I need to be sure that the fingerprint of the server-certificate is the one I would expect at the client side. Am I wrong? Are there other possibilities to prevent a man in the middle attack?

How can I do this with Corona SDK ways and possiblities? Any ideas? 

One possibility I found is described here: http://prosody.im/doc/depends/luasec/prosody

What I am suggesting, is that Corona updates luasec to version 0.5. This would give me the possibility to access the server certificate  and make a check that it delivers the correct SHA1 or MD5 fingerprint. Another nice thing would be that we can use Perfect Forwarding Secrecy that prevents captured/recorded SSL communication from being decrypted later (f.e. with more computing power in the future).

So please is it possible to update luasec to 0.5 or has somebody another idea to increase security?

Any help will be apreceated!

Jörg

#2

Jörg - This is of interest to me too. I’m afraid I have no answers for you but I too would be very interested to hear thoughts of someone who does.

When making a network request, what are the standard practices we can put in place to ensure the data being sent and received is safe from any kind of attack like this…?

Thanks.

Ian

#3

Just using official signed SSL certificates (for example bought by VerySign, Comodo, StartSSL, …) is kinda safe. These official certificates are issued from a trusted CA (CA - Certificate Authority) - assumed that you install the certificate correctly in your web server/backend application - they are able to encrypt your communication data safely.

But they do not protect against a man in the middle attack. Bad persons / bad governments / the NSA could easily use a proxy (http://mitmproxy.org) or surveillance software together with some fancy DNS spoofing or similar things and decrypt your communication data. They could read / capture your communication data in clear text including passwords or authentication tokens. After doing their evil thing they encrypt your data again and forward this encrypted data to you. They can not encrypt this data with your certificate (except they stole it from you). But they can use another valid trusted certificate from a trusted CA.

iOS or Android and Webbrowsers like Firefox are checking whether the domain you are surfing at is equal to the domain the certificate is issued for. They trust if this is true. Maybe they do some more checks. Unfortunately we know that CA’s have been hacked. Such a bad hacker / bad government / the NSA could easily create valid certificates for domains they do not own. No web browser will complain, the end user will notice nothing about this interception. 

But if we are talking about a well coded application with an own backend, then this is, where certificate pinning comes in. Because our application only connects to a specific server it can know the serial number and hash codes of this specific server certificate. A hacker / bad government / the NSA is not able to fake this data in a consistent way. So if we check the server certificate for these values we can be sure that we are not intercepted. Unfortunately this is not possible with Corona SDK because Corona does not includes luasec 0.5 but an earlier version. If you look at the documentation from luasec 0.5 you see that brunoos added support for getting the certificate serial number and checksums (https://github.com/brunoos/luasec/wiki/LuaSec-0.5, cert:serial and cert:digest).

One more thing: A bad hacker / bad government / NSA could save your recorded, encrypted communication data in a file and keep it until they have enough processing power / better encryption breaking / whatever. This is a very real threat because processing power is growing fast and they are even evaluating quantum computers to break encryption (not hackers, government and NSA for sure :slight_smile: ). This is where a mechanism called perfect forward secrecy comes in. I will investigate later what Corona SDK can do about this for us.

#4

Jörg - This is of interest to me too. I’m afraid I have no answers for you but I too would be very interested to hear thoughts of someone who does.

When making a network request, what are the standard practices we can put in place to ensure the data being sent and received is safe from any kind of attack like this…?

Thanks.

Ian

#5

Just using official signed SSL certificates (for example bought by VerySign, Comodo, StartSSL, …) is kinda safe. These official certificates are issued from a trusted CA (CA - Certificate Authority) - assumed that you install the certificate correctly in your web server/backend application - they are able to encrypt your communication data safely.

But they do not protect against a man in the middle attack. Bad persons / bad governments / the NSA could easily use a proxy (http://mitmproxy.org) or surveillance software together with some fancy DNS spoofing or similar things and decrypt your communication data. They could read / capture your communication data in clear text including passwords or authentication tokens. After doing their evil thing they encrypt your data again and forward this encrypted data to you. They can not encrypt this data with your certificate (except they stole it from you). But they can use another valid trusted certificate from a trusted CA.

iOS or Android and Webbrowsers like Firefox are checking whether the domain you are surfing at is equal to the domain the certificate is issued for. They trust if this is true. Maybe they do some more checks. Unfortunately we know that CA’s have been hacked. Such a bad hacker / bad government / the NSA could easily create valid certificates for domains they do not own. No web browser will complain, the end user will notice nothing about this interception. 

But if we are talking about a well coded application with an own backend, then this is, where certificate pinning comes in. Because our application only connects to a specific server it can know the serial number and hash codes of this specific server certificate. A hacker / bad government / the NSA is not able to fake this data in a consistent way. So if we check the server certificate for these values we can be sure that we are not intercepted. Unfortunately this is not possible with Corona SDK because Corona does not includes luasec 0.5 but an earlier version. If you look at the documentation from luasec 0.5 you see that brunoos added support for getting the certificate serial number and checksums (https://github.com/brunoos/luasec/wiki/LuaSec-0.5, cert:serial and cert:digest).

One more thing: A bad hacker / bad government / NSA could save your recorded, encrypted communication data in a file and keep it until they have enough processing power / better encryption breaking / whatever. This is a very real threat because processing power is growing fast and they are even evaluating quantum computers to break encryption (not hackers, government and NSA for sure :slight_smile: ). This is where a mechanism called perfect forward secrecy comes in. I will investigate later what Corona SDK can do about this for us.

#6

news on that?

#7

I’m on the same boat.

#8

news on that?

#9

I’m on the same boat.

#10

Any news?

#11

Someone filed a feature request way back in 2014 for this:

http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/5644165–plugin-please-update-luasec-to-version-0-5

There is only 11 votes for it. We probably are going to need to see more interest in this.

Rob

#12

I would find this useful too as this guide below was hacked by experts as allowing man in the middle attacks.

http://fearby.com/article/adding-a-commercial-ssl-certificate-to-a-digital-ocean-vm

#13

Any news?

#14

Someone filed a feature request way back in 2014 for this:

http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/5644165–plugin-please-update-luasec-to-version-0-5

There is only 11 votes for it. We probably are going to need to see more interest in this.

Rob

#15

I would find this useful too as this guide below was hacked by experts as allowing man in the middle attacks.

http://fearby.com/article/adding-a-commercial-ssl-certificate-to-a-digital-ocean-vm