3

There's something that bothers me: I'd like to distinguish between a packet coming from Youtube and a packet coming from Wikipedia: they both travel on HTTPS and they both come from the port 443.

Since they travel on HTTPS, their payload is not understandable and I can't do a full Deep Packet Inspection: I can only look at Ethernet, IP and TCP struct headers. I may look at the IP address source of both packets and see where they actually come from, but to know if they are from Youtube or Wikipedia I should already know the IP addresses of these two sites.

What I'm trying to figure out is a way to tell from a streaming over HTTP (like Youtube does) and a simple HTML transport (Wikipedia) without investigating the payload.

Edit 1: in a Wireshark session started during a reproducing video I got tons of packets. Maybe I should start looking at the timeout between packets coming from the same address.

elmazzun
  • 1,066
  • 2
  • 18
  • 44
  • 1
    May want to look at [Network Characteristics of Video Streaming Traffic](http://conferences.sigcomm.org/co-next/2011/papers/1569470149.pdf) (research paper, PDF format) – Mark Plotnick Oct 08 '15 at 15:57
  • Sorry, fixed (I had the `.` inside the `()` instead of after.) – Mark Plotnick Oct 08 '15 at 16:01
  • Thank you, I'll read it. – elmazzun Oct 08 '15 at 16:03
  • @Mark Plotnick, while the paper is *basically* right, it doesn't account for some fairly fundamental facts. First, the amount of data per-unit or even per-period of time is nowhere near constant. It will depend on how rapidly the frames are changing what's on the screen. A newscast with a few people sitting and talking will have very high compression while the camera angle doesn't change and high rate when the camera angle changes or when they go to someone on location. Sports and cartoons will have more consistent per-unit-of-time data rate, but cartoons will have less data than sports. – Dmitry Rubanovich Oct 08 '15 at 21:23

5 Answers5

1

If you are just interested in following the data stream in Wireshark you can use the TCP stream index, filter would be something like tcp.stream == 12

The stream index starts at zero with the first stream that wireshark encounters and increments for each new stream (persistent connection).

So two different streams between the same IPs would have two different numbers. For example a video stream might be 12 and an audio stream, between the same IP addresses, might be 13.

If you started the capture before the stream was initiated you'll be able to see the original traffic setting up the SSL connection (much of this is in clear text)

Peter_V
  • 49
  • 7
1

You may consider looking at the server certificate. It will tell you whether it's youtube (google) or facebook. Facebook certificate

That would give you an idea whether SSL connection is to youtube, which one is to facebook.

packetie
  • 4,839
  • 8
  • 37
  • 72
0

You can try looking at the TCP header options, but generally the traffic is encrypted for a reason... so that it wouldn't be seen by man-in-the-middle. If it were possible, it would be, by definition, a poor encryption standard. Since you have the capture and all the information known to the user agent, you are not "in-the-middle". But you will need to use the user agent info to do the decryption before you can really see inside the stream.

Dmitry Rubanovich
  • 2,471
  • 19
  • 27
  • I'll have a look at the TCP header options, maybe they contain infos about some features which distinguish packets involved in streaming from others packets. – elmazzun Oct 08 '15 at 16:08
0

this link: Reverse ip, find domain names on ip address

indicates several methods.

Suggest running nslookup on the IP from within a C program.

And remembering that address/ip values can be nested within the data of the packet, it may (probably will) take some investigation of the packet data to get to the originator of the packet

Community
  • 1
  • 1
user3629249
  • 16,402
  • 1
  • 16
  • 17
  • That's not a good aproach (well, can be for google or youtube, but not generally) as normally ISPs mount different web providers in the same host using the virtual host feature of http. from the ip traffic you cannot get anything, but the ip addresses and the port numbers. Everything else is encrypted. – Luis Colorado Oct 10 '15 at 13:46
0

Well, you have encountered a dilema. How to get the info users are interchanging with their servers when they have explicitly encrypted the information to get anonymity. The quick response is you can't. But only if you can penetrate on the SSL connection you'll get more information.

Even the SSL certificate interchanged between server and client will be of not help, as it only identifies the server (and not the virtual host you'll try behind this connecton), and more than one SSL server (with the feature known as HTTP virtual host) several servers can be listening for connections on the same port of the same address.

SSL parameters are negotiated just after connection, and virtual server is normally selected with the Host http header field of the request (see RFC-2616) but these ocurr after the SSL negotiation has been finished, so you don't have access to them.

The only thing you can do for sure is to try to identify connections for youtube by the amounts and connection patterns this kind of traffic exhibit.

Luis Colorado
  • 10,974
  • 1
  • 16
  • 31
  • Some kind of heuristic analysis? I may compare the packets' address from/to Youtube with a list of IP addresses which belong to Google Inc. (checking with the AS15169). Or I may count the packets coming from a Google IP address, and if I get lof of TCP ACKed packets probabilly there is a video buffering. I think that a buffering Youtube video will send me more packets than a simple Google query, right? – elmazzun Oct 11 '15 at 10:03
  • Nope, TCP ACKs are buried too deep in TCP traffic. Video streaming is something that can be done on TCP as you don't need quick response time, so you can spend even minutes filling your buffer, just to assure there will be enough buffer space to not interrupt it during the playback. There will not be more ACKs in a video download than in a normal file download. But this can be a pattern you can test if you like. It's the only thing you can do as you have no access to the inside of the connection. – Luis Colorado Oct 12 '15 at 05:20