I’d like to request a future enhancement to the FlightXML alert system: support for HTTPS endpoints.
I would like all data POSTed to my server to happen via HTTPS. Right now that isn’t supported by FlightAware - setting the endpoint works, but callbacks fail with “Unsupported URL type”. It would also be good if when posting via HTTPS, FlightAware does certificate validation of my endpoint.
Still really hoping for this feature in the future. Any plans to support it?
We’ll consider it for implementation in some future release in the next few months, but I cannot provide any estimated timeframe. We have many other higher priority features that have more demand and revenue associated with them. SSL negotiation will have a higher connection overhead for every alert that we have to deliver, which may mean that we need to allocate additional hardware and refactor our backend for more delivery parallelization.
What security aspect are you trying to protect against, and why do you feel your server infrastructure is particularly vulnerable to it? Origin authentication (spoofing by a third party), data confidentiality (evesdropping by a third party), data integrity (network corruption or malicious alteration), destination misdirection (DNS or network interception), etc.
I understand that you cannot make any promises or provide a time estimate. I’m glad to hear that FlightXML is in active development and that there’s a bunch of higher priority features being worked on.
To answer your questions, I don’t feel that my server infrastructure is particularly vulnerable to attack (my servers run on Google App Engine), but currently the FlightAware POST endpoint is the only insecure channel through which data is entering my system - the weakest link, as it were. Since these alerts can result in notifications to end users, I’d prefer it was secure and tamper-proof.
I’m currently doing IP checking to authenticate the origin of the POST request (see this previous post:http://discussions.flightaware.com/flightxml/flightxml-alert-remote-host-t14311.html) but this isn’t bulletproof - a checksum with a shared secret would be better. I’m most worried about data integrity or destination misdirection (data confidentiality is not really an issue here except that alert callbacks expose my alert_ids). It seems to me that SSL with certificate validation would be the best way to solve all of these concerns, but in the interim, since there’s a bunch of work on your side to support that, perhaps some other way of authenticating the POSTs as coming from FlightAware and being unaltered could be added? A checksum perhaps that can be verified using a shared secret - e.g. my account key?