TripIt insecurely broadcasts sensitive travel details in calendar feeds
httpshaming.tumblr.com
httpshaming.tumblr.com
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.
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.
Mmm, this may work...
http://krebsonsecurity.com/2014/06/peek-inside-a-professiona...
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.
Journalists do also report on emerging and widespread trends, however.
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.
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.
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.)
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.
The flight cards I got to my smartwatch when flying back from Finland last week were pretty handy with the gate info and everything...
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.
For big sites - probably their load balancers can't handle the https load.
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.
SSL certs are basically a cartel. They should work more like the PGP web of trust.
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.
I love TripIt, but they really need to fix this for me to keep using it.
The only way to avoid the dragnet surveillance we're currently experiencing is to take away the opportunity.
If you can't prove control of the domain, you absolutely should not be issued a certificate for it under any circumstances.
The Google/TripIt connection may be unencrypted, but I'm assuming (and hoping) that Google Calendar feeds are sent over HTTPS.
FWIW you can choose to disable "Include detailed items in your calendar feed" from Settings > Publishing Your Data.
tl;dr don't use pgp.mit.edu .
https://we.riseup.net/riseuplabs+paow/openpgp-best-practices
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.
> 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.
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.
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.
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.