Right, now that we are past the theory in Part 1 of this article, let’s jump straight into the dissection of the traffic flow.
First of all, we will not be looking at the entire traffic stream of the GDS application. We are not interested in its security for now, but rather whether it is establishing a typical web browser traffic. We need to assume that there is going to be some working knowledge on how networking works, else we will end up giving an entire lesson on it and not get to the point of this article. So, we are not going to explain TCP, HTTP(S) protocols, TLS, handshakes etc. Let’s just assume that we are beyond that and we just need to see if the GDS traffic is similar to the traffic we see on browsers.
In order to do that, we need to look at the basic communication over the internet – handshakes. Like its namesake, a handshake is between two systems – the client and the server and it’s a way of establishing communication. It’s a universally acceptable sign of friendship, although in some countries, it would be a hug, or kiss on the cheeks, or fistbumps. It’s the same thing. A TCP handshake is when your browser fistbumps the server.
However, in this case, because this is considered a “secure” channel we will be using what we know as a TLS (Transport Layer Security) Handshake.
This typically goes like:
a) Client Hello
b) Server Hello
c) Server Key Exchange
d) Client Key Exchange
e) Handshake
f) Let’s chat!
Now, again, this article is not to break down each item and explain every single packet details, but to make a comparison between GDS traffic vs an encrypted browser traffic, to say, Yahoo.com. So what we have done is to use a normal Chrome browser and go to mail.yahoo.com which throws us into the “HTTPS” page, which is the encrypted secure page and from there, we want to establish a connection by logging into Yahoo Mail and looking at the traffic. We are using Wireshark and here is the screenshot:
So as you can see, the beginning has a “Client Hello” packet from our system to Yahoo. This means we are saying, “Hey, here’s what I want from you and here are some information: my TLS version, my cipher suites, my compression method, the server name (so we know who we are talking to) etc. It’s like I give you a name card with all my information in it.
Next, we see a Server Hello. This is great so we know we are not talking to a brick wall. While the Client Hello has information in it, the Server Hello is not just courtesy, it also has piles of instruction on how to communicate. It’s like someone responding to us and saying, “OK, we will be talking in English, we will be using a phoneline at this number, at this time etc etc”. For internet connectivity, TLS versions, cipher suites are important to sync between Client and Server. We won’t go into details here as it is not the objective of this article.
If all goes well, the next step is the Certificate (remember, we are using a secure version of communication here). This certificate does a few things: It gives non-repudiation, meaning, the client knows that it is the server that is sending the information (instead of say, another server pretending to be the actual server). The certificate also provides the important “Public Key” of the server so encryption can occur and the server can decrypt using its own private key.
After this, there might be a Server Key Exchange, which is part of the negotiation flow. At the end of this packet, there is a “Server Hello Done” which is…what it says it is. The Hello is done. Likewise, a Client Key Exchange packet is followed if there is a Server Key Exchange, which in this case, there was. The client is basically encrypting the session with the public key of the server. After these, the TLS handshake is basically done and the transmission is considered secured, and you will see New Session Ticket.
At the end, you will see that “Application Data” packet is encrypted through TLS v1.2.
So this basically constitute a typical browser packet capture for secure communications.
Let’s compare what we get from Travelport:
So here you see the start of the conversation typically begins the same, except there is no Server Key Exchange, and basically the Travelport server sends the “Server Hello Done” message in the Certificate packet itself. This is no big deal, as this is an optional message and the server certificate has the required information.
The client key exchange here is sent to travelport based on the public key algorithm…for the sake of this discussion, this is perfectly normal to either have or not have this, as is the Change Cipher Spec. Finally a “Session Ticket” is also optional (it is missing here) , it’s based on RFC 5077, which basically is session caching on the client side which removes the tracking of each client session on the server side. It’s kind of like those special pass stamps you receive on your hand when you enter into a concert, when you need to take a leak and go outside, the bouncer recognises you on re-entry by the stamp on your hand and you don’t need to do a re-registration again. I really can’t think of another analogy here, so do forgive me if this flies over your head.
So from here, you can see Travelport Galileo Client is actually establishing the same sort of traffic that our Chrome established with Yahoo Mail on the browser. The only thing here we are not comfortable with is the fact that the protocol negotiated is TLS v1, which is not secure and broken. PCI-DSS would have some choice words to say to Travelport on this, as there is a requirement to migrate TLS v1 to v1.1 or v1.2 by June next year 2018.
So let’s look at Sabre:
Again, more or less the same as Travelport except here we have a “Encrypted Handshake Message” which usually occurs after “Change Cipher Spec” since now the messages are no longer unencrypted like the Client Hello, Server Hello etc. Again, it’s part of the normal handshake flow.
With the breakdown as such, we can see that the Travelport client and Sabre client are establishing the same sort of network flow as a browser authenticating to a website, and not doing any local authentication or getting local application data within the client application itself. This generally means, these are specialised “browsers” that are made for only one purpose: connecting to the GDS server. No Facebook access permitted here.
Again, we went through this because we needed some assurance that these GDS clients are functioning similar to browsers, as opposed to standalone payment systems, and from these packet capture, we can surmise (unless stated otherwise by the GDS, IATA or acquiring banks) that these clients are indeed “Internet Based Virtual Terminals”. This gives our travel agencies a measurable confidence to approach this channel with SAQ C-VT (as long as all the other eligibility requirements are met).
Thanks for reading this post, and as always, let us know if you have any queries regarding your PCI-DSS program, at pcidss@pkfmalaysia.com.
