[Disclaimer: I work for Mozilla but don't work in the area under discussion.]
Regarding this statement, [Mozilla] "forces anyone who wishes to use encryption to pay a certificate authority (CA) for a signed SSL certificate, which goes against the openness of the Web."
Firefox 3 ships with certificates for StartCom, who provide FREE certificates. So those people who claim that they have to pay are misinformed.
http://www.startcom.org/
Chris Snyder
· 1 year ago
YES! Thank you for making a big deal out of this. Releasing a web stack as big as Mobile Me without SSL support is an utterly brain-dead move. Was this coded in someone's basement in the middle of this night, or what?
iPhones are going to be used on untrusted networks. There WILL be man-in-the-middle attacks, and any Apple site is going to be a juicy target because of their security hubris. Let's hope they decide to actually get serious about it before their users' personal data starts getting wiped out.
Glenn Fleishman
· 1 year ago
Nice dissection. AppleInsider seems to be equating an initial authentication with subsequent security. Even if MobileMe connects you via SSL/TLS to provide credentials, the system then uses a token that cannot be cryptographically bound in the browser to the browser. This is why Google and other sites have overhauled how they handle token generation and communication, and why Gmail now offers an SSL/TLS option. Sidejacking was well explained by Errata Security in 2007; no one should be developing a service in 2008, like Apple, that relies on an initial secure authentication as the basis of subsequent communication.
Eric Johnson
· 1 year ago
Thanks for clearing this up, Thomas!
So now the next question: Is Mobile Me's syncing of contacts, calendar, etc. between Macs done over an encrypted channel?
Cause that's the same data, sent another way (though perhaps less of it as presumably only changed records are sent...)
Mo
· 1 year ago
@Chris:
While, yes, the web UI not being SSL-secured is incredibly incredibly stupid, this has nothing to do with iPhones. E-mail, at least, is accessed via IMAPS, and I'd be surprised if the calendaring wasn't over WebDAV over HTTPS.
But, I haven't got around to sniffing the traffic yet, so can't be completely sure about that.
El Aura
· 1 year ago
I think I read somewhere that Mobile Me syncing is done via IPsec.
Am I understanding it correctly that SSL only protects against MITM attacks if no self-signed certificates are used? And that DNS poisoning trumps almost anything (by first getting your credentials) except system which generate new credentials for each connection via additional hardware?
Tom
· 1 year ago
@Eric:
A quick peek at the MobileMe Mac sync traffic shows that it is encrypted. As Mo pointed out, they also provide IMAPS email, which is encrypted, so you Mail.app and iPhone mail is secure.
It's just the web portion of MobileMe that isn't encrypted. Arguably this is the piece that would most require encryption, since most people would be using it from public or otherwise untrusted networks.
Prince McLean
· 1 year ago
The article you sampled from neither states that MobileMe apps are 100% secure from any imaginable threat, nor says that SSL is unnecessary for securing web apps.
Instead, it was describing the potential security threat related to passing executable JSON objects. It described that the client app uses authenticated cookies to make sure it was talking to the server.
It also pointed out that because of that architecture, using SSL to secure the browser (as many claimed was necessary for security) would secure the files of the app itself, which really is unnecessary.
The unnecessary panic is caused by security experts talking about marginal risks and suggesting that MobileMe is hopelessly insecure. That's why you have comments here talking about how the iPhone presents a risk when being used at Starbucks, and questions about Macs exposing your data.
Before you attack a position, you should look at what it's actually stating, and not stuff a bunch of things in that you think it might be saying or suggesting or alluding to. And make sure your own argument doesn't go too far the other way in creating unfounded, misinformed panic.
El Aura
· 1 year ago
@Prince Can one read e-mails sent or retrieved via Mobile Me's web interface with a packet sniffer at Starbucks? Can one do it with Gmail? Or do you need a true MITM for that?
Tom
· 1 year ago
El Aura:
MobileMe Mac syncing appears to use SSL/TLS.
Regarding SSL and MITM: Sort of. Technically self signed certificatess can protect against MITM attacks, but the "user interface" issues causes problem in practice.
If you use a self signed certificate you will get the same warning you would get if you were subject of a MITM attack, thus there is no way to tell the difference, and many users will end up ignoring the warnings.
However, the first time you access a page with a self signed cert, you can tell the browser you trust that cert and you will no longer get the warnings. Now, in the future if you're the subject of a MITM attack the cert won't match the trusted one that you originally added, and you will get a warning.
In that case, a self signed cert can protect against MITM attacks, but you need to make the effort to add the cert the first time you visit the page in each browser you use, and that's assuming you can even trust it (ideally verified through some out-of-band mechanism).
So self-signed certificates can be used securely. The problem is that if the browser were to not warn me about self-signed certificates I would have no idea if a MITM attack were occurring. Additionally, by making the warnings easy to dismiss, users get in the habit of blindly dismissing them. Firefox 3's changes make it much harder for users to accidentally ignore the warnings.
DNS poisoning is one way to perform a MITM attack. SSL with a CA signed certificate is pretty much the only defense against that, since no one should be able to obtain a valid cert for bankwebsite.com (for example) that doesn't throw up warnings on user's browsers. I can generate a self-signed certificate for bankwebsite.com, but the browser will warn the user.
Matt Ryall
· 1 year ago
SSL only prevents man-in-the-middle attacks if you never accept an invalid certificate when the warning pops up in your browser. For most users, therefore, SSL provides no additional security aside from the transport encryption.
Even then, it still only helps with the one internet vulnerability we actually know how to solve. It doesn’t help with the security of the boxes at either end of the connection, which are far more likely to be the target of an exploit.
@Prince: the point is that the data sent between the browser and the MobileMe server is not encrypted, which is a security risk. The traffic can be sniffed in plaintext. Even if the authentication absolutely guarantees that the data being exchanged is only going to and from the real MobileMe server, and even if this authentication process itself is written in such a way that your account can't possibly be compromised (which is bluntly a very dubious proposition), all the data exchanged in the session can be compromised.
Furthermore, if the web connection to MobileMe was run over SSL, that wouldn't just "secure the apps," it would allow the apps to use that SSL connection to transfer the JSON data, which -- as explained above -- isn't being done now.
So yes, in fact, MobileMe's web applications are insecure, and yes, in fact, using SSL for it would go a long way toward fixing that problem.
Tom
· 1 year ago
@Prince:
Your article is highly misleading, as evidenced by John Gruber citing it and telling everyone that MobileMe is encrypted when it's really not. Whether or not you explicitly state such things, it's irresponsible to imply that the service is more secure than it really is, but I'm glad at least Gruber issued a correction.
"It also pointed out that because of that architecture, using SSL to secure the browser (as many claimed was necessary for security) would secure the files of the app itself, which really is unnecessary."
And I already pointed out that this is simply not true. If the app itself can be hijacked (and without SSL it could be) then all bets are off. But even if you were right, it doesn't matter in MobileMe's case since even the data isn't encrypted!
"The unnecessary panic is caused by security experts talking about marginal risks and suggesting that MobileMe is hopelessly insecure. That’s why you have comments here talking about how the iPhone presents a risk when being used at Starbucks, and questions about Macs exposing your data."
I would hardly call the fact that anyone with a packet sniffer on the same network (WiFi especially) as someone using the MobileMe site could read all emails, contacts, calender events, and files, a "marginal risk".
And yes, just as people have taken your article to mean MobileMe is more secure than it really is, it seems some people have taken my article to mean IMAP and desktop syncing are less secure. I've issued a clarification, I suggest you do the same.
Scott
· 1 year ago
@Tom:
And now word comes in that SSL certs aren't even a good protection from a MITM attack...
Slashdot notes a talk given at Black Hat where the presenter was able to get "testing" or "Internal Only" SSL certs that matched the URLs he was targeting from vendors that in the trusted root of common browsers.
These are usually only good for a week or so, but how long do you need to own a Starbucks WiFi spot before you've culled enough user id/passwords?
Jeremy
· 1 year ago
Where in the heck are you getting a server certificate for $15?
The entire SSL certificate industry is nothing more than a big protection racket. You pay the money so your users won't get ugly security warnings, and that's it.
I've been responsible for obtaining and renewing the SSL certificates the companies I've worked for in this business. The only "verification" they have ever done is "verifying" that they got their money. The effort it would take to obtain a browser-trusted certificate that says pretty much anything you want -- especially one of those 30-day "testing" certificates -- would be minimal.
Yeah, I'm sure some issuers do more verification than others, and some of them have multiple "levels" of certificates based on what information they are verifying. But how many users look at the certificates websites send, see what is verified, look at the issuer to decide how much verification was probably done, and then decide whether to trust the site? Zero. So this part of the system hardly even matters any more anyway (if it ever mattered in the first place as anything beyond theory).
Thus, a self-signed certificate actually provides MORE security than a "real" one, because with one of those, you can accept the certificate the first time and know that you're always hitting the same site you got the first time around, because a different self-signed certificate wouldn't be accepted. With a browser-trusted certificate, you'll never know if someone is posing as the site with a completely different, but still browser-trusted, certificate.
Tom
· 1 year ago
@Matt:
"SSL only prevents man-in-the-middle attacks if you never accept an invalid certificate when the warning pops up in your browser."
Yes, that's exactly why I'm all for Firefox 3 being more strict with invalid certificates.
I certainly wouldn't consider every WiFi access point "least likely avenues for a potential attacker". Without SSL, a kid with a laptop and Wireshark sitting in Starbucks can see your email.
@Scott:
That vulnerability appears to be specific to SSL VPNs, not browser's SSL. Not sure if it's applicable to browsers.
@Jeremy:
GoDaddy, etc gets you simple domain verified SSL certificates for $30 ($15 if you find a good deal). And as Gen pointed out, StartCom offers free certs.
Sure anyone can get an SSL certificate very easily, but only for domains they control. Now, try getting a CA signed SSL certificate for bofa.com, I dare you.
Whether or not the SSL certificate industry is "a racket" or not is irrelevant to the security SSL offers. As long as they're not issuing certificates for domains to people who shouldn't have them, it's a secure way to authenticate and encrypt sites (not taking into account the "user interface" problem of users blindly dismissing warnings).
There absolutely needs to be some way to verify a key belongs to the website you're accessing. SSL uses a CAs. PGP uses a "web of trust". I think SSL's solution is a pretty good one.
I'm all for some open solution that wouldn't cost anything while remaining secure, but until then we're stuck with paying the CAs.
Galley Hannon
· 1 year ago
Prince Mclean:
Tom:
And why would someone on an iPhone be using the Mobile Me site, Tom? Or more to the point: How could they? There's a lot of clarification that needs to be made with regard to this blog post.
Tom
· 1 year ago
@Galley:
This blog post never mentions the iPhone. What more do you want clarified?
Chris Snyder
· 1 year ago
So the clarification is that a non-SSL site is only used for software download?
Okay this isn't nearly as bad, and is, for better or worse, standard industry practice. But is the code signed? Is there any guarantee that you are getting it from Apple and not a man-in-the-middle?
Say what you want about the relative security of SSL certificates in the hands of different users, they are your only line of defense in this case.
If you know what to watch out for (certificate mismatch, unknown CA) then you can ensure your privacy. If you don't care, then fine, accept whatever certificate the server hands you. But some people do.
cornholio
· 1 year ago
Please don't advertise stuff you aren't really sure about and/or haven't tried out yourselves. StartCom does offer free CLASS 1 Certificates but Firefox 3 won't trust them as it comes with a preinstalled StartCom CLASS 3 Certificate only.
"In theory, there is no difference between theory and practice. But, in practice, there is." ~ Jan L. A. van de Snepscheut/Yogi Berra
rob
· 1 year ago
right on the money...
cornholio
· 1 year ago
Sorry - my mistake. I wasn't aware that you have to manually install the intermediate certificates on the server. My free CLASS 1 certificate is now accepted by Firefox. For more information on the topic have a look here: https://www.startssl.com/?app=21</p>
Mark Trimble
· 1 year ago
We use encryption as part of our backup suite. This however is taken care of from both development and update viewpoints by our software suppliers. We are planning launching a new related service (details are not relevant here) which we are developing ourselves but we want an outside source to look after the encryption. The service will be web based and the code will be php based. Can anyone recommend a cryptology code provider we could contracr the security and encryption for the project to?
All Comments
[Disclaimer: I work for Mozilla but don't work in the area under discussion.]
Regarding this statement, [Mozilla] "forces anyone who wishes to use encryption to pay a certificate authority (CA) for a signed SSL certificate, which goes against the openness of the Web."
Firefox 3 ships with certificates for StartCom, who provide FREE certificates. So those people who claim that they have to pay are misinformed.
http://www.startcom.org/
YES! Thank you for making a big deal out of this. Releasing a web stack as big as Mobile Me without SSL support is an utterly brain-dead move. Was this coded in someone's basement in the middle of this night, or what?
iPhones are going to be used on untrusted networks. There WILL be man-in-the-middle attacks, and any Apple site is going to be a juicy target because of their security hubris. Let's hope they decide to actually get serious about it before their users' personal data starts getting wiped out.
Nice dissection. AppleInsider seems to be equating an initial authentication with subsequent security. Even if MobileMe connects you via SSL/TLS to provide credentials, the system then uses a token that cannot be cryptographically bound in the browser to the browser. This is why Google and other sites have overhauled how they handle token generation and communication, and why Gmail now offers an SSL/TLS option. Sidejacking was well explained by Errata Security in 2007; no one should be developing a service in 2008, like Apple, that relies on an initial secure authentication as the basis of subsequent communication.
Thanks for clearing this up, Thomas!
So now the next question: Is Mobile Me's syncing of contacts, calendar, etc. between Macs done over an encrypted channel?
Cause that's the same data, sent another way (though perhaps less of it as presumably only changed records are sent...)
@Chris:
While, yes, the web UI not being SSL-secured is incredibly incredibly stupid, this has nothing to do with iPhones. E-mail, at least, is accessed via IMAPS, and I'd be surprised if the calendaring wasn't over WebDAV over HTTPS.
But, I haven't got around to sniffing the traffic yet, so can't be completely sure about that.
I think I read somewhere that Mobile Me syncing is done via IPsec.
Am I understanding it correctly that SSL only protects against MITM attacks if no self-signed certificates are used? And that DNS poisoning trumps almost anything (by first getting your credentials) except system which generate new credentials for each connection via additional hardware?
@Eric:
A quick peek at the MobileMe Mac sync traffic shows that it is encrypted. As Mo pointed out, they also provide IMAPS email, which is encrypted, so you Mail.app and iPhone mail is secure.
It's just the web portion of MobileMe that isn't encrypted. Arguably this is the piece that would most require encryption, since most people would be using it from public or otherwise untrusted networks.
The article you sampled from neither states that MobileMe apps are 100% secure from any imaginable threat, nor says that SSL is unnecessary for securing web apps.
Instead, it was describing the potential security threat related to passing executable JSON objects. It described that the client app uses authenticated cookies to make sure it was talking to the server.
It also pointed out that because of that architecture, using SSL to secure the browser (as many claimed was necessary for security) would secure the files of the app itself, which really is unnecessary.
The unnecessary panic is caused by security experts talking about marginal risks and suggesting that MobileMe is hopelessly insecure. That's why you have comments here talking about how the iPhone presents a risk when being used at Starbucks, and questions about Macs exposing your data.
Before you attack a position, you should look at what it's actually stating, and not stuff a bunch of things in that you think it might be saying or suggesting or alluding to. And make sure your own argument doesn't go too far the other way in creating unfounded, misinformed panic.
@Prince
Can one read e-mails sent or retrieved via Mobile Me's web interface with a packet sniffer at Starbucks? Can one do it with Gmail? Or do you need a true MITM for that?
El Aura:
MobileMe Mac syncing appears to use SSL/TLS.
Regarding SSL and MITM: Sort of. Technically self signed certificatess can protect against MITM attacks, but the "user interface" issues causes problem in practice.
If you use a self signed certificate you will get the same warning you would get if you were subject of a MITM attack, thus there is no way to tell the difference, and many users will end up ignoring the warnings.
However, the first time you access a page with a self signed cert, you can tell the browser you trust that cert and you will no longer get the warnings. Now, in the future if you're the subject of a MITM attack the cert won't match the trusted one that you originally added, and you will get a warning.
In that case, a self signed cert can protect against MITM attacks, but you need to make the effort to add the cert the first time you visit the page in each browser you use, and that's assuming you can even trust it (ideally verified through some out-of-band mechanism).
So self-signed certificates can be used securely. The problem is that if the browser were to not warn me about self-signed certificates I would have no idea if a MITM attack were occurring. Additionally, by making the warnings easy to dismiss, users get in the habit of blindly dismissing them. Firefox 3's changes make it much harder for users to accidentally ignore the warnings.
DNS poisoning is one way to perform a MITM attack. SSL with a CA signed certificate is pretty much the only defense against that, since no one should be able to obtain a valid cert for bankwebsite.com (for example) that doesn't throw up warnings on user's browsers. I can generate a self-signed certificate for bankwebsite.com, but the browser will warn the user.
SSL only prevents man-in-the-middle attacks if you never accept an invalid certificate when the warning pops up in your browser. For most users, therefore, SSL provides no additional security aside from the transport encryption.
Even then, it still only helps with the one internet vulnerability we actually know how to solve. It doesn’t help with the security of the boxes at either end of the connection, which are far more likely to be the target of an exploit.
I’ve written more notes on this here:
MobileMe doesn’t use SSL but don’t worry
@Prince: the point is that the data sent between the browser and the MobileMe server is not encrypted, which is a security risk. The traffic can be sniffed in plaintext. Even if the authentication absolutely guarantees that the data being exchanged is only going to and from the real MobileMe server, and even if this authentication process itself is written in such a way that your account can't possibly be compromised (which is bluntly a very dubious proposition), all the data exchanged in the session can be compromised.
Furthermore, if the web connection to MobileMe was run over SSL, that wouldn't just "secure the apps," it would allow the apps to use that SSL connection to transfer the JSON data, which -- as explained above -- isn't being done now.
So yes, in fact, MobileMe's web applications are insecure, and yes, in fact, using SSL for it would go a long way toward fixing that problem.
@Prince:
Your article is highly misleading, as evidenced by John Gruber citing it and telling everyone that MobileMe is encrypted when it's really not. Whether or not you explicitly state such things, it's irresponsible to imply that the service is more secure than it really is, but I'm glad at least Gruber issued a correction.
"It also pointed out that because of that architecture, using SSL to secure the browser (as many claimed was necessary for security) would secure the files of the app itself, which really is unnecessary."
And I already pointed out that this is simply not true. If the app itself can be hijacked (and without SSL it could be) then all bets are off. But even if you were right, it doesn't matter in MobileMe's case since even the data isn't encrypted!
"The unnecessary panic is caused by security experts talking about marginal risks and suggesting that MobileMe is hopelessly insecure. That’s why you have comments here talking about how the iPhone presents a risk when being used at Starbucks, and questions about Macs exposing your data."
I would hardly call the fact that anyone with a packet sniffer on the same network (WiFi especially) as someone using the MobileMe site could read all emails, contacts, calender events, and files, a "marginal risk".
And yes, just as people have taken your article to mean MobileMe is more secure than it really is, it seems some people have taken my article to mean IMAP and desktop syncing are less secure. I've issued a clarification, I suggest you do the same.
@Tom:
And now word comes in that SSL certs aren't even a good protection from a MITM attack...
Slashdot notes a talk given at Black Hat where the presenter was able to get "testing" or "Internal Only" SSL certs that matched the URLs he was targeting from vendors that in the trusted root of common browsers.
http://it.slashdot.org/article.pl?sid=08/08/18/202223 links to http://www.networkworld.com/community/node/31124 Check paragraph 3 where the attacker was able to generate a cert for a Live.com host.
These are usually only good for a week or so, but how long do you need to own a Starbucks WiFi spot before you've culled enough user id/passwords?
Where in the heck are you getting a server certificate for $15?
The entire SSL certificate industry is nothing more than a big protection racket. You pay the money so your users won't get ugly security warnings, and that's it.
I've been responsible for obtaining and renewing the SSL certificates the companies I've worked for in this business. The only "verification" they have ever done is "verifying" that they got their money. The effort it would take to obtain a browser-trusted certificate that says pretty much anything you want -- especially one of those 30-day "testing" certificates -- would be minimal.
Yeah, I'm sure some issuers do more verification than others, and some of them have multiple "levels" of certificates based on what information they are verifying. But how many users look at the certificates websites send, see what is verified, look at the issuer to decide how much verification was probably done, and then decide whether to trust the site? Zero. So this part of the system hardly even matters any more anyway (if it ever mattered in the first place as anything beyond theory).
Thus, a self-signed certificate actually provides MORE security than a "real" one, because with one of those, you can accept the certificate the first time and know that you're always hitting the same site you got the first time around, because a different self-signed certificate wouldn't be accepted. With a browser-trusted certificate, you'll never know if someone is posing as the site with a completely different, but still browser-trusted, certificate.
@Matt:
"SSL only prevents man-in-the-middle attacks if you never accept an invalid certificate when the warning pops up in your browser."
Yes, that's exactly why I'm all for Firefox 3 being more strict with invalid certificates.
I certainly wouldn't consider every WiFi access point "least likely avenues for a potential attacker". Without SSL, a kid with a laptop and Wireshark sitting in Starbucks can see your email.
@Scott:
That vulnerability appears to be specific to SSL VPNs, not browser's SSL. Not sure if it's applicable to browsers.
@Jeremy:
GoDaddy, etc gets you simple domain verified SSL certificates for $30 ($15 if you find a good deal). And as Gen pointed out, StartCom offers free certs.
Sure anyone can get an SSL certificate very easily, but only for domains they control. Now, try getting a CA signed SSL certificate for bofa.com, I dare you.
Whether or not the SSL certificate industry is "a racket" or not is irrelevant to the security SSL offers. As long as they're not issuing certificates for domains to people who shouldn't have them, it's a secure way to authenticate and encrypt sites (not taking into account the "user interface" problem of users blindly dismissing warnings).
There absolutely needs to be some way to verify a key belongs to the website you're accessing. SSL uses a CAs. PGP uses a "web of trust". I think SSL's solution is a pretty good one.
I'm all for some open solution that wouldn't cost anything while remaining secure, but until then we're stuck with paying the CAs.
Prince Mclean:
Tom:
And why would someone on an iPhone be using the Mobile Me site, Tom? Or more to the point: How could they? There's a lot of clarification that needs to be made with regard to this blog post.
@Galley:
This blog post never mentions the iPhone. What more do you want clarified?
So the clarification is that a non-SSL site is only used for software download?
Okay this isn't nearly as bad, and is, for better or worse, standard industry practice. But is the code signed? Is there any guarantee that you are getting it from Apple and not a man-in-the-middle?
Say what you want about the relative security of SSL certificates in the hands of different users, they are your only line of defense in this case.
If you know what to watch out for (certificate mismatch, unknown CA) then you can ensure your privacy. If you don't care, then fine, accept whatever certificate the server hands you. But some people do.
Please don't advertise stuff you aren't really sure about and/or haven't tried out yourselves. StartCom does offer free CLASS 1 Certificates but Firefox 3 won't trust them as it comes with a preinstalled StartCom CLASS 3 Certificate only.
"In theory, there is no difference between theory and practice.
But, in practice, there is." ~ Jan L. A. van de Snepscheut/Yogi Berra
right on the money...
Sorry - my mistake. I wasn't aware that you have to manually install the intermediate certificates on the server. My free CLASS 1 certificate is now accepted by Firefox. For more information on the topic have a look here:
https://www.startssl.com/?app=21</p>
We use encryption as part of our backup suite. This however is taken care of from both development and update viewpoints by our software suppliers.
We are planning launching a new related service (details are not relevant here) which we are developing ourselves but we want an outside source to look after the encryption. The service will be web based and the code will be php based. Can anyone recommend a cryptology code provider we could contracr the security and encryption for the project to?
Thanks
Mark
http://www.backupanytime.com/contact.htm</p>