Firesheep is one app that proved just how easy it is to hijack sessions from sites like Twitter and Facebook when the communication is sent plain-text over HTTP. Thus, if you have any kind of high profile site, SSL has become a MUST. Without SSL, it doesn’t matter what security measures you use or how clever you are because a Man-in-the-Middle (MitM) can simply send your users his own, unsecured, version of your website without all your clever security, your users will happily send the MitM all the information unsecured, and then the MitM can send the data up to your server using your clever security measures…and nobody will ever know the MitM was even there. So, I wish there was another answer, but if you truly want your site to be secure, you must use SSL.
The prevention for an MitM attack is NOT the Asymmetrical RSA encryption like some people probably think. By itself, RSA encryption only prevents passive attackers from reading communications sent between two parties. If encryption is the only security used, then someone who controls the router at your local Starbucks could route all amazon.com traffic to their own computer, and when a user requests amazon.com, they could send the user their own public key, and the user would happily encrypt all their user and credit card information using the attackers public key and send it to the attacker. The attacker would then decrypt it, harvest all the information, encrypt it with amazon’s public key and send it up to amazon.com, and vice-versa. The MitM would be able to sit in the middle harvesting all the information sent between the two parties and be completely invisible…that is…IF encryption were the only security. Fortunately for us, it’s not.
It is not the RSA encryption that makes SSL secure, but rather the Trusted Certificate Authority (CA). When a user connects to a website over SSL, the browser takes the domain name they THINK they are on, the IP address they are actually connected to, and the “public key” (certificate) they were given and verifies all that information against a CA that the browser knows it can trust. If some of the information doesn’t match what the CA has on file, or the website used a CA that your browser doesn’t trust, then the user gets a very ugly security warning from the browser telling the user not to trust the site
Using a signed certificate from a CA, given the same scenario above where the attacker routes all amazon.com traffic to their own computer at IP 10.10.0.10, when the user’s browser reads the certificate and tries to verify it, it will find that the amazon.com certificate they received was “self-signed” or from a CA it doesn’t know or trust, etc., and the subsequent browser warning will hopefully scare the user away. Thus, the only way for an MitM to get away with such a scenario would be to get a Trusted CA to issue them a certificate for amazon.com, which is why CAs make you jump through hoops to get a certificate and charge so much money. CAs actually have a lot of responsibility to their clients and to users whose browsers trust them.
In any case, if you need a secure site, you MUST use SSL. If you don’t use SSL, you will ALWAYS be vulnerable to an MitM attack. By adding more complicated security, you can make it a lot more work for an MitM, and if you have a small user-base, less MitMs will have the opportunity to be in a position to compromise your site. However, ultimately, no matter what you do, your site is vulnerable to MitM attacks without SSL and a signed certificate from a Trusted CA.
Kevin Nelson February 7th, 2015
Posted In: Security
Let’s say that your server runs in Central Time but it logs data for facilities all across the US. 99% of the time you won’t have any problem. You’ll grab the Date/Time out of the database, and if displaying to a facility on the East Coast, you convert the Date/Time to Eastern for the user to see. It’s all good. However, you set yourself up for a very big headache in the Fall.
In the Fall, the clocks will move back, which means that your server will experience 1am – 2am twice. If MySQL stored the offset in the DateTime field (e.g. -05:00 before the change and -06:00 after the change), then this wouldn’t be a problem. However, since it doesn’t, when you pull a log out of the table and get the time 1:30am, you have no way of knowing which 1:30am it is, the one before or the one after the change.
If only you had stored the times in UTC you would know which was which.
However, we have a bigger problem. Your Easter timezone facilities’ clocks don’t change back at the same time…they change back at their own 2am. This means that when you translate back and forth between Central and Eastern time, you are going to run into some odd glitches illustrated below. The “Time In” is the valid time sent from the Eastern timezone facility, the “Time Stored” is the time that it gets converted to on the local machine before storage. The “Time Out” is the translation back to local machine time when it pulls it out of the table, and the “Display Time” is the end-result that you display in your logs for the Eastern timezone facility.
|Time In||Time Stored||Time Out||Display Time|
|01:00 EDT||00:00 CDT||00:00 CDT||01:00 EDT|
|01:30 EDT||00:30 CDT||00:30 CDT||01:30 EDT|
|01:00 EST||01:00 CDT||01:00 CDT||01:00 EST|
|01:30 EST||01:30 CDT||01:30 CDT||01:30 EST|
|02:00 EST||01:00 CST||01:00 CDT||01:00 EST|
|02:30 EST||01:30 CST||01:30 CDT||01:30 EST|
|03:00 EST||02:00 CST||02:00 CST||03:00 EST|
You’ll notice that you’re all good up until you get to 2:00am EST. Your local machine converts it to local time as 01:00 CST, which is correct. However, since MySQL doesn’t store the offset, when your local machine pulls it out of the database table, it translates it to 1:00am CDT since it doesn’t know which. This results in your Eastern timezone logs having 3 instances of 1am – 2am instead of 2, and a complete loss of the logs from 2am – 3am.
Therefore, if you are working with multiple timezones, or your business might grow to include multiple timezones…start things off the right way. You can avoid this problem by storing your DateTimes in any format that is immune to DST changes. So, the following will all work:
It can be a bit of a pain getting used to storing data in UTC and then translating it into the display timezone later. However, it avoids many pitfalls, and the work you do up-front to get used to it will pay off in the long run.
Kevin Nelson December 18th, 2014
Posted In: Software Design