BUGS.txt

   1 In future, bugs should migrate to the SourceForge tracker:
   2
   3 https://sourceforge.net/tracker/?func=browse&group_id=233013&atid=1088569
   4
   5 Switzerland probably contains many bugs.  Here are some important ones:
   6
   7 Usability:
   8
   9  - Control-c mightn't always exit the application properly (this is a thread
  10    management issue, and has been largely but maybe not entirely fixed).
  11
  12 Security against network adversaries:
  13
  14  - We don't use SSL yet.
  15
  16  - Switzerland doesn't send HMAC keys to Alice and Bob yet.
  17
  18  - Until we do both of the above, adversaries who could be bothered could find
  19    a way to modify packets such that the hash fragments matched anyway, so
  20    Switzerland wouldn't notice.
  21
  22 Other security issues:
  23
  24  - It is possible for the switzerland client to quit in such a way that it does
  25    not shred & delete the temporary file used for packet capture.  This would
  26    leave copies of raw captured packets on the system's hard disk.  (On unusual
  27    copy-on-write or versioning filesystems, this might be the case even if we
  28    call shred.  We won't fix that.)  [MOSTLY FIXED, but we should probably
  29    catch a few signals and handle those.]
  30
  31 Semantics:
  32
  33  - The firewall penetration code needs to know about transport layer protocols.
  34    It currently works for TCP, UDP, SCTP and port-less protocols, but not for
  35    some other protocols like RDP.  Fixes should go in Packet.py!
  36
  37  - If a network modifies a flow from the very first packet, we currently won't
  38    realise that we're seeing both ends of the flow.  This is because the "flow
  39    matchmakers" in Switzerland.py are currently (src_ip, dst_ip,
  40    hash_of_opening_packet_with_some_fields_masked).  Those criteria are good
  41    for penetrating firewalls, but if we have a very weird NAT or network that
  42    changes a field we wouldn't dream of masking (like the IP DO_NOT_FRAGMENT
  43    flag, which we've seen modified by Netgear MR814v2 wireless routers, for
  44    instance), we won't handle it well.  We now tell the user when this occurs,
  45    but we should really try some other matchmaking strategies in cases where
  46    the existing algorithm isn't working.
  47
  48    This is scheduled to be improved in release 0.2.0
  49
  50  - We need to be more consistent in our responses to crazy NATs.
  51
  52  - We don't reassemble fragmented packets.  This means that packets which are
  53    fragmented in transit will be reported as dropped, when in fact they should
  54    arrive correctly
  55
  56  - Severely mangled packets may be reported as "injected".  For instance, if
  57    a packet is so truncated that our parser chokes on it, switzerland may not
  58    correctly report the packet as "modified".
  59
  60 Performance:
  61
  62  - The current matchmaking and reconciliation algorithms are designed to work
  63    well for large flows.  Large numbers of tiny flows, such as those seen
  64    during port scans, have not been optimized at all.  We don't know how many
  65    simultaneous port scans the current client and server can handle.
  66
  67  - FastCollector / PacketListener currently exchange packets through an mmap'd
  68    array.  Alternative implementations are possible, and will store more
  69    packets per byte of RAM than we currently do (currently, small packets take
  70    up as much space as large packets).
  71