

TripIt insecurely broadcasts sensitive travel details in calendar feeds - jyujin
http://httpshaming.tumblr.com/post/94950343491/tripit-insecurely-broadcasts-sensitive-travel-details

======
donkeyd
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.

~~~
onion2k
_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.

~~~
riquito
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.

Mmm, this may work...

~~~
onion2k
Crime As A Service is essentially what Moriarty does in the Sherlock Holmes
novels. Make you wonder if it's ever been done for real...

~~~
brohee
The once stealing CC informations are not the one using it usually, the whole
"carding" scene is based on CaaS.

------
drglitch
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.

------
mjs
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.)

~~~
toddn
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.

------
toyg
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.

~~~
bergie
I'm still a TripIt user, but it seems Google Now is replacing that feature
more and more (if you allow it to scan your email).

The flight cards I got to my smartwatch when flying back from Finland last
week were pretty handy with the gate info and everything...

~~~
christop
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.

------
ismaelc
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!

------
plg
What's the big impediment to just making all websites https, all the time?
Technical? Financial? Honest question.

~~~
monort
For small sites it's mostly certificate and dedicated IP price. Wildcard
certificates price is especially egregious.

For big sites - probably their load balancers can't handle the https load.

~~~
sbarre
A wildcard SSL certificate is $250 per _year_. You can't tell me that this is
a prohibitive cost for someone operating a serious business.

~~~
onion2k
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.

------
rdl
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.

------
colinbartlett
I wonder if we can ever look forward to a day when unencrypted http just
doesn't exist. When the only option is https?

~~~
userbinator
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.

~~~
fabulist
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.

~~~
MichaelGG
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.

------
martingordon
Hmm, I guess it's a good thing I proxy through Google Calendar then, huh?

The Google/TripIt connection may be unencrypted, but I'm assuming (and hoping)
that Google Calendar feeds are sent over HTTPS.

------
JoeAltmaier
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.

~~~
joshdance
He's not talking about getting robbed, he is talking about someone changing or
canceling your airline reservation.

~~~
JoeAltmaier
Wha? The article changed after my comment? Strange.

~~~
NDizzle
That's HN for you. Seeing what they want us to see.

~~~
JoeAltmaier
HN has nothing to do with the original article?

------
cV6WB
Wow – this is terrible.

FWIW you can choose to disable "Include detailed items in your calendar feed"
from Settings > Publishing Your Data.

------
michaelrshannon
Wow - I've been a huge advocate for TripIt in the past - definitely need to
pause using it though until they get this sorted :/

~~~
mseebach
Just don't use the "export" feature, or use it securely, eg. by exporting to
Google Calendar.

------
nodata
The other pages on this site are pretty good: Little Snitch, Scribd, PGP..

~~~
fabulist
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. >.<

tl;dr don't use pgp.mit.edu .

~~~
tonywebster
Author here. If you let me know some sources for the above, I'd love to add
them. Contact info in profile. Thanks!

~~~
fabulist
I believe I originally heard that here:

[https://we.riseup.net/riseuplabs+paow/openpgp-best-
practices](https://we.riseup.net/riseuplabs+paow/openpgp-best-practices)

------
jqueryin
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._

~~~
sandy12
Did you even read the entire post?

> 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.

~~~
jqueryin
If you browse through other posts on the blog, you'll notice a recurring
pattern of no mention of disclosure.

~~~
mikeash
So, what, it's OK to be wrong about this one because it applies to other
cases?

~~~
jqueryin
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.

~~~
tonywebster
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.

~~~
mikeash
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.

