[Cryptography] Firewall penetration

[Jehan Tremback]

You might want to look into how WebRTC does it. There are several different
strategies and fallbacks.

-Jehan

On Wed, Feb 1, 2017 at 7:42 AM, Jerry Leichter <leichter at lrw.com> wrote:

> > Suppose a server talks to two clients, which are connected to the
> internet by ordinary consumer type connections.  Is their any reliable,
> practical, generally useful way whereby it can arrange for the two clients
> to talk directly to each other, or is it more practical for all data to be
> stored on the server by one client, and then collected by the other client?
> >
> > When last I looked at this issue, direct communication was getting
> harder, and workarounds were like bugs that were likely to be fixed.
> I'm not sure what you're referring to.  We are not yet at the point where
> "ordinary consumer connections" can't listen for incoming traffic, nor
> where outgoing traffic to such endpoints is blocked.  Yes, there are some
> special cases (mainly for mail, to block spam) but it's not a general
> phenomenon.
>
> There are two common issues.  First, "ordinary consumer connections" don't
> have static IP's, so finding your target requires something special.  Two
> solutions are common:  Dynamic DNS, which follows the varying IP address
> around as it changes; and third-party "rendezvous" sites which come down to
> the same thing, just effectively using a private namespace separate from
> DNS.  Some of these "rendezvous" sites may act as proxies, allowing both
> ends to have outbound connections and simply forwarding the traffic onward;
> others pass along the needed information and then let the endpoints connect.
>
> The second issue is consumer-level firewalls.  But there are
> commonly-implemented protocols allowing hosts behind the firewall to create
> openings through it.
>
>                                                         -- Jerry
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170201/0625d060/attachment.html>