Obfuscated TCP

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • bascule
    omgpwnies!
    • Jul 2003
    • 1946

    #1

    Obfuscated TCP

    Obfuscated TCP is an idea I've been following for awhile. As we all know, commodity Internet traffic is transmitted in plaintext and readable for anyone who has access to tha part of tha tubes where ur precious infoz are flowin'

    The most common solutions for ensuring privacy are SSL/TLS which aim to solve a number of problems simultaneously, including secure encrypted communication and identity validation which further enhances security by attempting to prevent MITM attacks and so forth.

    However, identity verification works only as well as you can trust the person doing the verification (see Zooko's triangle) and the best assurances we have that someone is who they claim to be come only from the fact that they've paid a trusted individual to vouch for them. What kind of trust is that?

    Obfuscated TCP doesn't try to solve the identity problem or MITM attacks (although the latter can potentially be solved in conjunction with obsctp using technologies like DNSSEC and DNSCurve).

    Instead, Obfuscated TCP, in its latest incarnation, uses DNS to determine if a particular host offers Obfuscated TCP, and if so opens a connection with it. Obfuscated TCP just encrypts your connection. There's no certificate chain. There's no popups warning you of invalid identities. If someone wants to MITM you they still can (but of course that applies just as much to plaintext TCP). All Obfuscated TCP aims to do is provide the simplest way of encrypting your traffic seamlessly so as to prevent third party snooping.

    So what do you think? Good idea? Bad idea?
    12
    Good idea
    75.00%
    9
    Bad idea
    25.00%
    3
    BrokenCbl is one sexy ass bitch
    0%
    0
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
    [ redacted ]
  • TheCotMan
    *****Retired *****
    • May 2004
    • 8857

    #2
    Re: Obfuscated TCP

    Originally posted by bascule
    Obfuscated TCP is an idea I've been following for awhile. As we all know, commodity Internet traffic is transmitted in plaintext and readable for anyone who has access to tha part of tha tubes where ur precious infoz are flowin'

    The most common solutions for ensuring privacy are SSL/TLS which aim to solve a number of problems simultaneously, including secure encrypted communication and identity validation which further enhances security by attempting to prevent MITM attacks and so forth.

    However, identity verification works only as well as you can trust the person doing the verification (see Zooko's triangle) and the best assurances we have that someone is who they claim to be come only from the fact that they've paid a trusted individual to vouch for them. What kind of trust is that?

    Obfuscated TCP doesn't try to solve the identity problem or MITM attacks (although the latter can potentially be solved in conjunction with obsctp using technologies like DNSSEC and DNSCurve).

    Instead, Obfuscated TCP, in its latest incarnation, uses DNS to determine if a particular host offers Obfuscated TCP, and if so opens a connection with it. Obfuscated TCP just encrypts your connection. There's no certificate chain. There's no popups warning you of invalid identities. If someone wants to MITM you they still can (but of course that applies just as much to plaintext TCP). All Obfuscated TCP aims to do is provide the simplest way of encrypting your traffic seamlessly so as to prevent third party snooping.

    So what do you think? Good idea? Bad idea?
    I'd have concerns about compatibility through various devices, but that would depend on the implementation of Obfuscated TCP. If the implementation is just payload, size and checksum modification, then I don't see why it wouldn't work like other tcp packets in a session. However, if special flags are altered in non-standard, or unexpected ways, or other header items are altered in non-standard ways, then there is much higher risk for compatibility issues, especially in stateful examination packet/session filters, and NAT devices.

    Next, support for such a system would almost certainly require a driver for the OS to exist on both sides, and support with access to unfiltered DNS access to pull TXT records, or whatever records are used to pass information and advertising of availability. If a driver, then you might have a huge "kernel" or "system" fooprint, compared to a vpn, which only need a generic, standard, tunnel interface and a user-space service that talks to/through that interface. (Of course, it is hard to compare an exiting implementation to assumptions of what an implementation of oTCP might be like.) A new "system" space driver, increases risk for system crash. We're talking kernel programming, and system programming and bugs in this space tend to influence OS stability (during beta development) in unhappy ways.

    Also, comparing what exists here to a VPN that runs over UDP, say, UDP port 53, which would more likely work on more networks? Additionally, with a vpn HUB in the public, multiple NAT-ed users on dissimilar networks can all join the same hub and communicate with each other, and have the encryption, and defense against MiM attacks with SSL and a centrally trusted certificate on the hub. (Everyone playing on the hub trusts the hub, and the hub is what they connect to use.)

    Now, as for an academic endeavor, this is a great idea. I like it when people are able to take ideas like this and run with them. It becomes an excellent learning opportunity, and sometimes can fork totally new ideas which have no parallels.

    Maybe I am just missing something, but this reminds me a little bit of port-knocking as a new look at using existing infrastructure in a new or different way, to duplicate an existing, well defined system. (In the case of port-knocking, "authentication," was being re-invented.)

    If you do go with this, and decide to implement it, it would be great to hear about your progress, and what you learn along the way. :-)
    Last edited by TheCotMan; November 12, 2008, 20:29.

    Comment

    • xor
      not
      • Aug 2007
      • 1347

      #3
      Re: Obfuscated TCP

      fo shizzle my nizzle; about the TCP.

      xor
      Just because you can doesn't mean you should. This applies to making babies, hacking, and youtube videos.

      Comment

      • xor
        not
        • Aug 2007
        • 1347

        #4
        Re: Obfuscated TCP

        Originally posted by TheCotMan
        stuff cotman wrote
        So you think it is a ______________ idea? Poll?

        Just being anal and busting your #$%^ a little

        xor

        Or is BrokenCbl one sexy ass bitch?
        Just because you can doesn't mean you should. This applies to making babies, hacking, and youtube videos.

        Comment

        • TheCotMan
          *****Retired *****
          • May 2004
          • 8857

          #5
          Re: Obfuscated TCP

          Originally posted by xor
          So you think it is a ______________ idea? Poll?

          Just being anal and busting your #$%^ a little

          xor

          I should edit the poll and add a new option...
          * "I'm glad Bascule starts some of the more technically interesting threads on the forums"

          :-)

          Or is BrokenCbl one sexy ass bitch?
          BrokenCbl is a jerk. That guy owes me money.

          Comment

          • bascule
            omgpwnies!
            • Jul 2003
            • 1946

            #6
            Re: Obfuscated TCP

            Originally posted by TheCotMan
            Next, support for such a system would almost certainly require a driver for the OS to exist on both sides,
            In its initial implementation, yes, however after it was proposed to the IETF and rejected, the encryption was moved out of the transport layer. The whole thing runs in userspace now the same way SSL/TLS libraries do.

            and support with access to unfiltered DNS access to pull TXT records, or whatever records are used to pass information and advertising of availability.
            It'd need a special DNS resolver which is integrated with the connection setup process, yes. However, that isn't too hard to write and can be done in userspace.

            Also, comparing what exists here to a VPN that runs over UDP, say, UDP port 53, which would more likely work on more networks?
            If you're talking about connecting to servers you or your organization controls, then yes, IPSEC is a fine solution. However, Obfuscated TCP's end goal would be to encrypt *all*
            Internet traffic (at least going over TCP) such that efforts to wiretap Internet traffic would be mostly useless.

            If you do go with this, and decide to implement it, it would be great to hear about your progress, and what you learn along the way. :-)
            It's already implemented, actually...
            45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
            45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
            [ redacted ]

            Comment

            • YenTheFirst
              Member
              • Aug 2008
              • 282

              #7
              Re: Obfuscated TCP

              If the goal is only to encrypt traffic, not protect against MiM attacks, how is this different at all from using SSL and accepting any and all certificates?
              It's not stupid, it's advanced.

              Comment

              • bascule
                omgpwnies!
                • Jul 2003
                • 1946

                #8
                Re: Obfuscated TCP

                Originally posted by YenTheFirst
                If the goal is only to encrypt traffic, not protect against MiM attacks, how is this different at all from using SSL and accepting any and all certificates?
                It's not trying to usurp SSL's role completely, and the identity verification provided by SSL is still useful for detecting forgeries / MitM. It wouldn't be good to just throw it all away.

                It's trying to be transparent, so that encryption is used opportunistically.
                45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
                45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
                [ redacted ]

                Comment

                • Voltage Spike
                  Ce n'est pas un personne
                  • Jun 2004
                  • 1049

                  #9
                  Re: Obfuscated TCP

                  Originally posted by bascule
                  It's trying to be transparent, so that encryption is used opportunistically.
                  Isn't the other aspect that the overhead is much lower than "real" encryption? Thus, you could introduce oTCP without significantly impacting throughput.

                  I suppose it's okay to deter casual observers (probably 99% of all attacks), but it may serve to give a false sense of protection while leaving you open to the attackers best able to hurt you. *shrug*

                  Comment

                  • bascule
                    omgpwnies!
                    • Jul 2003
                    • 1946

                    #10
                    Re: Obfuscated TCP

                    Originally posted by Voltage Spike
                    Isn't the other aspect that the overhead is much lower than "real" encryption?
                    It uses Elliptic Curve Cryptography (Curve25519) for the private key exchange and Salsa20 as the stream cipher.

                    Wikipedia reports:

                    As of 2008, Aumasson, Fischer, Khazaei, Meier, and Rechberger reported a cryptanalytic attack against Salsa20/7 with a time complexity of 2151, and they reported the first attack against Salsa20/8 with an estimated time complexity of 2251. This attack makes use of the new concept of probabilistic neutral key bits for probabilistic detection of a truncated differential. The attack can be adapted to break Salsa20/7 with a 128-bit key. There are no published attacks on Salsa20/12 or Salsa20.
                    Emphasis on that part at the end, I suppose...

                    It's all designed to be fast and low-overhead, while still remaining cryptographically effective.
                    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
                    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
                    [ redacted ]

                    Comment

                    Working...