Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am running encrypted communication with ping tacked on after decryption and deserialization is complete.

I.e.

incoming data -> split into packets -> decrypt -> deserializer -> actual message or ping

outgoing message or ping -> serializer -> encrypt -> send

I would prefer ping be handled before any decryption happens and make it part of the lowest socket layer instead.

What I wonder is if I introduce any weakness this way. (The actual crypto layer may be TLS or similar).

I don't see how manipulating the unencrypted ping would enable much, given that I only use it to test the liveness of the connection and get a RTT.

Am I overlooking something?

EDIT:

Just so this is clear - it relates to a custom server-client protocol for a game. The "ping" here is simply a special packet periodically sent from server to client and then back again.

This helps both client and server ensure that communication is open, one can implement the check "if ping isn't seen within x seconds, assume that the connection is broken".

share|improve this question

1 Answer 1

Your question is quite unclear on the particulars, so I assume that you mean the following:

  • You have some sort of VPN going on between machine A and machine B, and the VPN encapsulates all IP packets from A to B and from B to A within an encrypted tunnel which probably uses SSL/TLS for the encryption part.

  • The VPN picks up all packets, whether they relate to TCP, UDP or ICMP.

  • You are wondering whether making the ICMP Echo packets (aka "ping") travel outside of the VPN, unprotected, would open vulnerabilities.

Under these conditions, the answer seems to be "no, it does open any vulnerability" under the following argument: VPN protection is about protecting some specific traffic, between A and B, against interferences from outsiders. As long as your "important traffic", the one you wish to protect, still goes through the VPN, then that traffic will keep on being protected. Note, though, the following points:

  • It may be hard to configure a VPN software to exclude, explicitly, ICMP Echo requests and replys, but still include TCP and, crucially, other ICMP message types. While the "ping" protocol is pretty benign, some other ICMP messages can be important for proper network traffic propagation. Also, since a "ping" consists in a request and then a reply, both ends of the tunnel (machines A and B) should be configured to not-protect the ICMP packet.

  • You do a "ping" for a reason. If the "ping" is unprotected, then it can be altered by attackers, which may impact the reason why you do the ping. Attackers could block either the request or the reply, simulating a "down" machine (arguably, if they can do that, they can also block all the VPN traffic as well, so that point could be quite moot).

  • A "ping" going outside of the VPN tests whether the machine on the other side is up and running, but, by definition, it will not test whether the VPN link is also up and running. The other machine could be up but the VPN service down, and then the "ping" will not tell it to you. Thus, handling the "ping" outside of the VPN does not offer the same functionality as an in-VPN "ping".

  • Similarly, in many VPN setups, one of the machines actually is a complete local network containing many machines with private IP addresses. A "ping" request going through the VPN can be directed to any of these machines with private IP. A "ping" outside of the VPN can reach only machines with a non-private, Internet-reachable IP address, i.e. the VPN gateway. There again, functionality is different.

This also begs the question: why would you want an "unprotected" ping ? The only reason I see is when the VPN appears to be down or unresponsive, and you want to know whether the culprit is the VPN software on the other side, or the network in-between.

share|improve this answer
    
I've clarified the usage. It's not a VPN connection but a custom protocol over a single connection. –  Nuoji Aug 16 '13 at 13:45
    
In that case, what I say still mostly applies. You protect your "custom protocol" but that does not mean that you have to protect every other protocol on the machine; see for instance all the https:// Web site which use SSL for the HTTPS, but not for anything else. However, if you want to make sure that your service is up and running, as opposed to simply check that the server machine is up, then an in-protocol sort-of-ping message can be handy. –  Tom Leek Aug 16 '13 at 13:56
    
Both would be in-protocol. The question is if one puts the ping at the packet dispatch/read layer, or if it should be done much higher up, on equal standing with normal (usually encrypted) messages. –  Nuoji Aug 16 '13 at 15:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.