The case of using the info at a hotel to get your room key is pretty reasonable. On the home break-in story however there's a lot of evidence that this hardly ever happens if it happens at all. There are plenty analog ways in which criminals scout for homes where the occupants are on vacation. These ways are often much more efficient than their digital counterparts.
I'm not saying this article should be disregarded, however if you're on holiday and you used TripIt's feed on public WiFi, the chance that you're house was broken into because of this is negligible.
On the home break-in story however there's a lot of evidence that this hardly ever happens if it happens at all.
What evidence would/could there be? Someone sophisticated enough to be wifi sniffing HTTP calls on open networks for details of when people are travelling is unlikely to then just do a straightforward smash and grab burglary. Even just the fact they're bothering with information gathering in the first place points to a criminal who's bit cleverer than your typical housebreaker.
I'm not saying you're wrong, just questioning whether there'd be enough data points to suggest one way or the other. It could be a 'common' method of scouting places to burgle among criminals who manage to not get caught.
Yes, I would rephrase that as, "there's hardly any evidence that this happens at all." It's almost impossible to tell why a thief robbed a particular empty house unless they are caught and confess.
An evil organization may build a CAAS (crime as a service, TM since now :-p) and the little burglars may buy a 1.99$ app to know if there is a free house nearby.
There was a story few years back about burglars using Facebook status updates to find homes where owners were not home: http://bits.blogs.nytimes.com/2010/09/12/burglars-picked-hou...
So there is some evidence of using internet for this purpose. Those (supposedly) public Facebook updates are easier to find than TripIt calendars though.
The Dutch police force set-up two teams:
- One team of people with experience in scouting houses, who were sent on the road to find targets
- One team of IT experts wo were given the assignment to find targets via social media
The results were that spotting houses in the more 'traditional' way was about 8 times more effective than through social media. Therefore there's a much bigger chance they spot it with traditional methods, i.e. twig against front door.
So you have a much bigger chance of avoiding a break-ins by asking you neighbors to check your front door once a day (if you trust them..), than you do by not using leaky apps.
Also, at an airport it's much more effective for a burglar to spot tickets and baggage lables, than it is to sit down and hope that somebody connects to their access point and opens a valuable insecure connection.
The very fact that there's a story about it on nytimes.com is reason to think that it's uncommon. If it was common then it wouldn't be newsworthy.
Edit: what's with the downvotes? This is an easy and fairly reliable heuristic: if it shows up on the news, it's not worth worrying about, because newsworthy stuff is rare pretty much by definition.
As OP and many others have said, airline confirmation numbers are a pretty big personal security risk - an international itinerary always carries passport #, address, emergency info, et.
A very bad practice I've seen over and over are people doing boarding-pass-selfies in airports, inadvertently exposing their confirmation numbers to entirety of their twitter/instagram/facebook feed.
At best, you can move your buddy's girlfriend to be next to you on a flight instead, at worst, you can cancel their flight or move them to an earlier/later one. At very worst, you can use the plethora of PI data for ID theft.
The "http" calendar URLs (now?) actually redirect to "https" URLs, but this doesn't help retrospectively, since the only thing that needs to be kept secret is the URL, and that's redirected in plain text…
TripIt's web UI actually present the "private" calendar URL with a "webcal" scheme--is that typically secure? (You can replace "webcal" with "https" and things work just fine, though.)
FWIW, both Google Calendar and the subscribed calendar on iOS attempt to access webcal:// URIs over SSL on port 443. I'm not sure at what point they would fall back to http; if they do, I haven't seen it.
The good side of it is that this hole doesn't seem to be actively exploited on a significant scale. Feed urls cannot be harvested without sniffing traffic for each and every user, and profit is very indirect.
The bad side of it is that TripIt/Concur don't seem very responsive on the issue. It often feels like TripIt is on life support, really, which is a shame -- I use it extensively because of its wonderful "just forward to plans@tripit.com" feature.
Unfortunately, you need to have a Gmail account to get all the various automated hotel/car/flight reservation and parcel tracking notification stuff.
It would be nice if there was an API into Google Now (or even a Tripit-style email to selectively forward to) to insert such events, for those who can't use or choose not to use Gmail.
Hi guys, Chris here, Developer Evangelist at Concur. I just got word from the TripIt team that they are aware of the issue and working to get it fixed. Feel free to email me at chris.ismael@concur.com if you have questions. Thanks!
Advertising is the big impediment for anyone that is ad-driven. Most ad networks don't provide HTTPS for ads. Kind of infuriating in this day and age, really.
There are technical considerations - until we have full SNI coverage (Android 2.x is the big hole there right now), you can't really run HTTPS on shared hosting (or any place where you have multiple domains on the same IP).
And there are financial considerations - while an SSL certificate isn't expensive, if you're using a CDN or doing any kind of otherwise serious data delivery, SSL is many times more expensive per-byte than HTTP is. If there isn't financial risk mitigation gained by switching to HTTPS-only, it may not make sense from a business perspective.
It's probably technical - this is exporting to external calendar apps. I think it's perfectly plausible that a large number of broadly used calendar apps just don't support HTTPS imports, and probably fails in desperately graceless way - and so the decision is between supporting the feature insecurely, supporting the feature securely, but dealing with tons of customers, many of them both paying and technically unsophisticated experiencing a failure that they ascribe to TripIt and maybe do, maybe don't contact support about - or not supporting the feature at all.
Dedicated IP? I thought SNI was supported just about everywhere by now. Also, if all you need is a certificate for one subdomain (or maybe a couple of certificates for one subdomain each), a StartSSL certificate is free. It's not SuperDuperSign Extra Validation Plus Platinum, but it's accepted by all major browsers ;)
EDIT: Wikipedia tells me "As of November 2012, the only major user bases whose browsers do not support SNI appear to be users of Android 2.x (default browser), Internet Explorer on Windows XP and versions of Java before 1.7 on any operating system." - a small company should be fine.
The Python SNI situation was also cleared up very recently, with commits to some of the widely used libraries only happening in mid-2013. I wouldn't be surprised if many installations haven't yet upgraded to those post-2013 versions. See e.g.: https://github.com/shazow/urllib3/pull/156
For an established business that you know is going to make thousands of dollars in the next year it's trivial, but for a new business with an unknown future it's a pretty big addition. If setting up a new venture had a minimum cost of $250 (rather than being close to $0 as it is now) we'd see fewer side projects and part-time entrepreneurs.
Wildcards are under $100 at Namecheap, and in most cases a business that can't afford $100/year probably doesn't need a dozen subdomains and can go with the $7/year for www.
The concept behind httpshaming is great, although it would be nice if there were a softer/more positive initial request to the sites to add https. However, it's not like https is new; even post-Snowden is over a year now.
I love TripIt, but they really need to fix this for me to keep using it.
I'm in favour of encryption for protecting sensitive data (TripIt is violating this principle), but don't think it should be needed for publicly accessible information. The centralised CA model is probably one of my biggest gripes about using HTTPS.
CAs are unfortunate, but the reality is that all data is sensitive to some degree. TripIt's data is more sensitive than, say, which Wikipedia article I'm reading, but that still gives away a huge amount of information about what my current thought process is and where its going.
The only way to avoid the dragnet surveillance we're currently experiencing is to take away the opportunity.
And an attack can also modify data. Even "public" data, like Wikipedia info, could be valuable to modify. You can attack a user that way by providing misleading information. Or carry out XSS-like attacks. Or just insert spammy links or redirections all over the page.
As I see it, that is actually the problem here. As things stand, if you don't have the resources to go through the process for proving your identity (or have other reasons for not wanting to do so) to establish the certificate, then you are unable to have encryption, or at least not without raising an error message in your users' browsers.
The cheap certificates are domain-controlled, meaning that "proving your identity" is just "proving control of the domain name", such as by clicking a link in an email sent to a listed whois contact address.
If you can't prove control of the domain, you absolutely should not be issued a certificate for it under any circumstances.
Strawman? Has anybody ever been robbed due to a high-tech criminal intercepting their calendar data? Keep in mind that most breakins are by local teenagers looking for a thrill. And they are much more likely to know you're going on vacation because they're your neighbors.
Its important to note that they're pointing the finger at the MIT PGP keyserver, which has long been notorious for being poor in the security department. This is not even the worst of their crimes; for a long time (perhaps still?) they were ignoring key revocations. Meaning, if your key was stolen and you sent out a message declaring it void, people using pgp.mit.edu would never get the message. >.<
This is a nicely detailed post of uncovering the flaw (Thanks Wireshark!) and explaining the implications.
My biggest concern with this post and the entirety of the blog is that I'm not sure as to whether you're performing full disclosures before the shaming. It'd be irresponsible not to give the team time to respond and remedy. It'd be a quick addition to the footer to blanket that you do full disclosures and give an adequate amount of time before posting.
Edit: not sure if this post in particular had the disclosure statement added after my comment, but most of the other blog posts are devoid of disclosures.
Not sure if the author added this in response to your comment, but it is there - see the last paragraph.
Only my own information was accessed in these screenshots, and I manually changed the name from mine to John Doe. I contacted TripIt / Concur Technologies about this issue via e-mail and Twitter NINE MONTHS AGO and never heard back. A similar TripIt calendar feed security issue was brought up on the TripIt-maintained Get Satisfaction website OVER SIX YEARS AGO, with no resolution.
> Only my own information was accessed in these screenshots, and I manually changed the name from mine to John Doe. I contacted TripIt / Concur Technologies about this issue via e-mail and Twitter NINE MONTHS AGO and never heard back. A similar TripIt calendar feed security issue was brought up on the TripIt-maintained Get Satisfaction website OVER SIX YEARS AGO, with no resolution.
I was wrong but that's not the core point of the comment. What I'm driving home is nondisclosure is irresponsible and I would hope that's not the route taken.
HTTP Shamer here. I absolutely practice 'responsible disclosure' when it is appropriate.
In the case of TripIt, they've known about this issue for a VERY LONG TIME and chose not to address it. I'm incredibly sad about this because I absolutely love TripIt.
There's several sites and apps I've either found out about myself or have been submitted to the Tumblr that I do think warrant responsible disclosure, and I've either done that or am working on that. Sadly, only one of those vendors even has a security e-mail address with a responsible disclosure policy.
In the case of Scribd, if you're using HTTP for all of your account activity, it's not going to be encrypted, period. I'm not going to responsibly disclose that passwords are sent cleartext over HTTP because that's obviously what happens with HTTP. If the vendor made any attempt to use SSL that appears broken, I would stop and responsibly disclose.
In the case of apps going out and checking for updates insecurely, I think that behavior is prevalent enough to see, and obscure enough to exploit, that responsible disclosure doesn't really apply. It's just that HTTPS is something I'd like to see on developer roadmaps. There's been good discussions about this on Twitter, including the VLC team closing a ticket about it.
If I saw personally-identifiable information being sent from an app, I would stop and responsibly disclose.
Personally, I don't see how responsible disclosure can really apply to cases like this.
This is not some obscure vulnerability. It's a deliberate design decision with obvious tradeoffs. It's analogous to a bank keeping deposits sitting on tables in front of the building. It's obvious to anyone who looks, and it should have been obvious to the person who came up with the scheme.
The point of responsible disclosure is to give companies a chance to fix a vulnerability before it becomes widely known. That doesn't work when the problem is obvious to anyone who glances at it, because you've lost your chance at "before".
For something like "you can hijack session cookies sent over an unencrypted connection", I can see how that would warrant responsible disclosure. But for "this entire feed is dedicated to sensitive information, and it's sent in clear text by the very nature of the protocol you've chosen to deliver it", it doesn't seem like it works.
I'm not saying this article should be disregarded, however if you're on holiday and you used TripIt's feed on public WiFi, the chance that you're house was broken into because of this is negligible.