According to the specification of Bittorrent tracker (https://wiki.theory.org/BitTorrentSpecification) peer is identified by their peer_id and ip. peer_id is passed to tracker in announce request, ip - from request headers, but optionally can be passed as a query parameter. How tracker knows that this request was actually sent from this peer (not a fraud) without any key?
Note that the official specification lists that parameter as optional, meaning that it is not part of the identity of the client. Rather it should be considered as a hint to the tracker that the tracker should hand out that IP to other clients instead of the source of the announce connection. This hint should be ignored if the tracker doesn't trust the client.
Trust can be established if a client authenticates itself to the tracker (e.g. via HTTP basic auth or a secret token in the announce URL).
Instead of trusting the client the tracker could also verify it, e.g. by opening a bittorrent connect to the IP and port that was announced and then send a bittorrent handshake for the infohash that was announced to check if the remote can accept bittorrent connections. That also has the advantage of rejecting announces that aren't reachable due to firewalls or NAT limitations.
For open, public trackers neither approach is practical, so they usually ignore the &ip=... parameter. Trackers deployed in more restricted environments do make use of the trust and/or verify approaches.
Related
I'm making TLS client connections in Node.js. Some servers I communicate with request a client certificate. I'd like to be able to detect when this has been requested, so I can log it. At the protocol level I believe this is sent along with the TLS server hello, so the data is there, but I'm not sure how I can get at it.
I'm never actually providing a client certificate for now, I'm just aiming to report which servers requested one.
I think there's probably two cases here:
A cert has been requested, not provided, and the server has accepted the connection anyway (and then probably given my some kind of 'not authenticated' response).
A cert has been requested, not provided, and the server has rejected the TLS connection entirely.
At the moment I can't detect either case, solutions for either or both very welcome.
WebRTC traffic is encrypted using DTLS - ok. But what about traffic that's relayed over a TURN server?
I'm looking for a reliable resource which confirms that the traffic is truly end-to-end encrypted (because "end-to-end" can sometimes mean several things). So I mean
NOT that there's an "end-to-end" encryption between a peer and the TURN server.
But rather,
that it is end-to-end between the peers
such that it is not decrypted/re-encrypted on the TURN server
AND that there is no way for the TURN server to get access to the secret
I haven't been able to find a definite answer to this.
The place to look is the TURN proposed standard, RFC 5766. The standard provides a means for relaying UDP packets containing application data between a client and a peer:
Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the appropriate peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data.
The highest layer that TURN parses is the UDP layer. It does not understand or modify the application data layer (in your case, the WebRTC protocol). The standard says:
An application wishing to ensure that its data is not altered or forged must integrity-protect its data at the application level.
This implies that you can integrity-protect your application data, and TURN will relay it without modification. You can also look at the details of the TURN protocol (which I won't repeat here) that show that it merely wraps and forwards application data.
Finally, the standard says this on eavesdropping:
Confidentiality for the application data relayed by TURN is best
provided by the application protocol itself, since running TURN over
TLS does not protect application data between the server and the
peer. If confidentiality of application data is important, then the
application should encrypt or otherwise protect its data. For
example, for real-time media, confidentiality can be provided by
using SRTP.
The recommendation in this excerpt is to protect confidentiality by encrypting application data with a protocol such as DTLS-SRTP, which WebRTC uses.
Because TURN does not interpret or modify application data, it doesn't add any security vulnerabilities to WebRTC application data traffic that wouldn't be present without using TURN. WebRTC data is encrypted between WebRTC endpoints.
Now, no one can guarantee that there is "no way for the TURN server to get access to the secret." A rogue TURN server could attempt a man-in-the-middle attack on your connection just as easily as anyone else who can intercept your network packets. It's only true that using a TURN relay doesn't weaken WebRTC security.
As long as DTLS is implemented and used properly and assuming the DTLS algorithms and ciphers are secure, WebRTC traffic should be secured end-to-end. Part of using any SSL-based scheme requires verifying the certificate of the other endpoint, just like HTTPS. And just like HTTPS, this will require a prior out-of-band exchange of certificate identity or use of a trusted third-party. And just like HTTPS, if certificates are not properly verified then the door will be open for a MITM attack (by anyone, not just TURN servers).
In BitTorrent, client connects to the tracker specified in .torrent file. Tracker is a kind of centralized server and it is the starting point. So BitTorrent is not pure p2p.
If we want to develop pure p2p system, we should design routing overlay network. All nodes will have routing table like routers do. But even in routing overlay network, each node should know at least one existing node(GUID, IP address) initially. So how can we determine this? Should we keep 'one existing node to connect initially' forever like fixed centralized server? If so, I think this is not fully decentralized method.
The solution you describe (defining a central peer wit well-know ip address) is not the only one.
The other solution is to post an html page (or json file) in a well-know URL on the net, and make sure this item contains an updated list of peers this peer can initialy connect. This list can be updated if a peer goes down. Eventually, you can use multiple URLs.
Pure P2P system is a theoretical concept which cannot be implemented fully in reality.
You could use an anycast. So the first other client will answer and may send such an initial "client list". Where your client can connect to them to get more lists.
Classically I would implement a multicast to a adress and wait for an answer of other clients.
Firstly, a true peer to peer network is not necessarily decentralized. Secondly, decentralization does not necessarily mean that the network doesn't make use of secondary services which may themselves be centralized.
The main question in both of these issues is wheather the primary resources of the network solution are distributed through correlated peers.
For example, peer-to-peer video conferencing may use a central contacts service but still be pure peer-to-peer as long as the peers resolve such issues before entering a true peer-to-peer scope. This would also be decentralized.
What it comes down to is what your trying to solve by using peer-to-peer. A video conference is a video conference - it starts with a video being recorded on one peer and ends with the video being viewed on another. As long as each byte of this data is transferred directly between the peers (even if there's hundreds of peers in the conference, and regardless of how these peers found each other) it is a true peer-to-peer video conference.
Note that the video peers will still be in your typical ring, and that the contacts lists may still use the node key for location information rather than an IP. This will still be a network overlay as it will still be built over IP, replacing it's addressing scheme on the peer level to facilitate true peer-to-peer networking.
What it realy comes down to is the concepts of a network connection. IP just pushes packets to unspecified routers until it gets to a specific address. 'connections' between each endpoint only exist within the higher software levels (including when dealing with TCP/IP). A connection is just the data used within software to understand who is who and how each point can handle data etc. Peer-to-peer network overlays effectively distributes this data, eliminating the need for each peer to create massive amounts of connections to communicate on a massive scope. Decentralization is not required for this (as long as peer to peer communication is not centralized), and a secondary service within the system wont necessarily limit a network's scope or otherwise centralize actual peer-to-peer networking.
So to answer your question, it doesn't matter where it initially connects in order to be considered peer-to-peer, and different peer-to-peer services will handle this based on their service design.
Ok so I am thinking about writing a p2p protocol for a number of different services for an AI project, and I thought I'd come here to see if i could get some ideas on how to get the initial connection.
I have come across several ways to establish the initial connection:
1) You have a static ip address on the internet that distributes information on other peers. This isn't good, because:
a) it's a single point of failure, the service could go offline, preventing any new connections from creating an initial connection to peers,
b) the IP address could change. This could be mitigated by using a domain name which is maintained to point to the current ip address of the location of a service which provides data on peers, however this can be subverted in theory by hackers by spoofing or arp poisoning, dns attacks etc.
2) You could force the user to provide an initial ip address or hostname for another peer, and it's up to the user to find the hostname / ip address / port number. This is good, but if someone posts disinformation or they cannot find a peer on google or some other search site then obviously it's fallable.
3) You could leave it to the peer to publish their own existence in a central location - for example a group of IRC channels or a group of websites. Again, unless it's going through a central trusted domain, it's hard to determine the authenticity of the peer.
4) You could use some kind of nmap style discovery algorithm that searches through subnets for appropriate protocols. The problem with this approach is it's slow and it's likely to attract attention from things like firewalls etc.
5) This is a variation of 3) you could allow the peers to advertise their own information on a website, then instead of having to look for the information in a suitable location (a specific website, or group of websites), you can let google's search algorithm find it, and do the discovery for you, however you could imagine that this may take a few days for google to cache the website data with information on the peers. Also again, it would be upto you to provide some way to verify the authenticity of the advertised data.
6) If you are interested in an exclusive p2p network that locks out certain people (for example, you might want to have a file sharing network and you don't want law enforcement to be able to access it, or MPIAA), then you could use 2) and then have a referral system where you require that the initial connection provide the referrer's ip address, and then the service could connect to the referrers ip address and ask the referrer if they did indeed refer the referee.
That's all I can think of currently, but if anyone comes up with any other ways to do this, i would be very interested.
I have an interesting network security challenge that I can't figure out the best way to attack.
I need to provide a way to allow two computers (A and B) that are behind firewalls to make a secure connection to each other using only a common "broker" untrusted server on the internet (somewhere like RackSpace). (the server is considered untrusted because the customers behind the firewalls won't trust it since it is on an open server) I can not adjust the firewall settings to allow the networks to directly connect to each other because the connections are no known ahead of time.
This is very similar to a NAT to NAT connection problem like that handled by remote desktop help tools (crossloop, copilot, etc).
What I would really like to find is a way to open an SSL connection between the two hosts and have the public server broker the connection. Preferably when host A tries to connect to host B, it should have to provide a token that the broker can check with host B before establishing the connection.
To add another wrinkle to this, the connection mechanism needs to support two types of communication. First, HTTP request/response to a REST web service and second persistent socket connection(s) to allow for real-time message passing.
I have looked at the techniques I know about like OpenSSL using certificates, OAuth, etc, but I don't see anything that quite does what I need.
Has anyone else handled something like this before? Any pointers?
You can solve your problem with plain SSL.
Just have the untrusted server forward connections between the client hosts as opaque TCP connections. The clients then establish an end-to-end SSL connection over that forwarded TCP tunnel - with OpenSSL, one client calls SSL_accept() and the other calls SSL_connect().
Use certificates, probably including client certificates, to verify that the other end of the SSL connection is who you expect it to be.
(This is conceptually similar to the way that HTTPS connections work over web proxies - the browser just says "connect me to this destination", and establishes an SSL connection with the desired endpoint. The proxy just forwards encrypted SSL data backwards and forwards, and since it doesn't have the private key for the right certificate, it can't impersonate the desired endpoint).
In general, SSL is packet-based protocol (for the purpose of solving your task). If you can have the host forward the packets back and forth, you can easily have SSL-secured communication channel. One thing you need is something like our SSL/TLS components, which allow any transport and not just sockets. I.e. the component tells your code "send this packet to the other side" or "do you have anything for me to receive?" and your code communicates with your intermediate server.
According to the following quote, SSL provides point-to-point security:
Transport security is used to provide
point-to-point security between the
two endpoints (service and client).
If there are intermediary systems
between the client and the server,
each intermediate point must forward
the message over a new SSL connection.
a) What is meant by SSL providing point-to-point security?
b) Is SSL communication still possible between client and server, if intermediary system ( located between the client and the server ) forwards the message over a non-SSL connection?
c) Assuming it is possible ... I don't see why intermediary system forwarding messages over a non-SSL connection would provide less security, since messages are already encypted by original sender ( which is either client or server ) and thus can't be decrypted by an intermediary systems?
thank you
EDIT:
One limitation of transport security
is that it relies on every “step” and
participant in the network path having
consistently configured security. In
other words, if a message must travel
through an intermediary before
reaching its destination, there is no
way to ensure that transport security
has been enabled for the step after
the intermediary (unless that interme-
diary is fully controlled by the
original service provider). If that
security is not faithfully reproduced,
the data may be compromised
downstream. In addition, the
intermediary itself must be trusted
not to alter the message before
continuing transfer. These
considerations are especially
important for services available via
Internet-based routes, and typically
less important for systems exposed and
consumed within a corporate intranet.
Message security focuses on ensuring
the integrity and privacy of individ-
ual messages, without regard for the
network. Through mechanisms such as
encryption and signing via public and
private keys, the message will be
protected even if sent over an
unprotected transport (such as plain
HTTP).
I think the context of that quote is different than you seem to be assuming; by 'intermediate system', I think that quote means a system that must access the message in the middle (intentionally or not)... not just a router, but something actually decrypting, viewing and/or modifying the message.
Therefore, because SSL is 'point to point', the above is actually not possible without another, separate connection being made.
The messages are encrypted at the endpoints. The only way to have a non-SSL connection in the middle would be to emulate both endpoints somewhere in the middle, which would be extraordinarily difficult barring flaws in the SSL implementations on either of the endpoints.