Selbstverständlich geht das mit PhonerLite.
Wenn man ohne SIP-Server arbeitet, dann nennt man das eine Peer-to-Peer (P2P) Verbindung. In diesem Fall darf also KEINE Adresse bei "Proxy/Registrar" in der Konfiguration stehen.
Stell dir vor, du hast 2 PCs in einem LAN. PhonerLite auf PC A kann einfach PhonerLite auf PC B anrufen, indem die IP-Adresse von PC als Ziel eingegeben wird. Fertig.
Befinden sich beide PCs jeweils hinter einem Router, so macht dieser Router NAT, d.h. der Router hat eine öffentliche IP-Adresse (adressierbar über das Internet), die PCs dahinter haben eine private IP-Adresse (nur im eigenen LAN/WLAN adressierbar).
Genau dieses NAT bereitet nun Probleme, wenn man P2P Verbindungen über das Internet aufbauen möchte. Das hat erstmal überhaupt gar nichts mit PhonerLite zu tun.
Ein Teilnehmer aus dem Internet kann einzig und allein die Adresse deines Routers bestimmen (IP-Adresse und Port). In deinem Router musst du nun sicherstellen, dass Verbindungen an diesen Port auch auf einem PC im LAN/WLAN gelangen - das erfolgt über Port-Forwardings. Ein Port-Forwarding kann man entweder direkt im Router konfigurieren oder ein PC im LAN/WLAN kann per UPnP dynamisch ein solches Port-Forwarding einrichten, wenn denn der Router das erlaubt. Zu erklären, wie das funktioniert, führt an dieser Stelle zu weit.
In PhonerLite selbst kann man einen lokalen Port einrichten, per Default steht der auf 5060. Da manche Router selbst diesen Port auch verwenden, sollte man in PhonerLite einen anderen Port einstellen, also beispielsweise 5070. Ich gehe im Folgenden immer von diesem Port 5070 aus.
Folgende Ports verwendet dann PhonerLite:
5070 UDP: SIP Signalisierung UDP
5070 TCP: SIP Signalisierung TCP
5071 TCP: SIP Signalisierung TLS
5072 UDP: RTP
5073 UDP: RTCP

Wenn also kein UPnP verwendet werden kann oder möchte, dann müsste man obige Ports im Router "forwarden".
Das macht man typischerweise auf beiden Routern. Beide Router sollten auch eine DynDNS Adresse haben.
Beispiel:
PC A hängt am Router A und dieser hat die DynDNS-Adresse a.dyndns.org
PC B hängt am Router B und dieser hat die DynDNS-Adresse b.dyndns.org

A ruft nun B folgendermaßen an: b.dyndns.org:5070
B ruft nun A folgendermaßen an: a.dyndns.org:5070

Wenn du nun eine verschlüsselte Verbindung haben möchtest, dann solltest du in PhonerLite auf TLS stellen und dann den Port 5071 adressieren, also b.dyndns.org:5071

Bei Verwendung eines SIP-Servers ist das alles viel einfacher!

Quote:

Genau. Pro Anbieter und für P2P legst du jeweils ein Profil an und schaltest je nach Verwendung um. Gleichzeitig kannst du leider nicht mehrere Accounts laufen lassen.

Quote:

Genau das wollte ich damit ausdrücken.

Quote:

Im Internet-Cafe wirst du typischerweise nicht angerufen, sondern du rufst nur von dort an.

Quote:

Das ist die Adresse, welche du anrufst, wenn du es so willst, also die "Telefonnummer". Die gibst du jeweils als Zieladresse ein oder eben ins Telefonbuch.

Quote:

Wenn es rein um die Verschlüsselung der Sprache geht, dann kannst du ZRTP verwenden. Damit hast du eine Ende-zu-Ende-Verschlüsselung - da kann der Anbieter in der Mitte nichts abhören.

Quote:

Das hat nichts mit P2P zu tun. Bei Verwendung von TLS benötigt man Zertifikate - wie bei HTTPS auch. Wenn du von PhonerLite per P2P ein anderes PhonerLite über TLS anrufst, dann geht das auch so, ohne dass du etwas konfigurieren musst. Es gibt ein eingebautes Zertifikat, weshalb es damit erstmal geht. Selbstverständlich kannst du auch eigene Zertifikate konfigurieren.

deti wrote on 17. Dec 2011 at 17:04:


Du magst recht haben, aber selbst wenn DynDNS nicht funktioniert gibt es hundert andere Möglichkeiten, an die IP des Anzurufenen zu kommen. Bei einem ausgefallenen (redirect) SIP-Server würde einem die IP-Adresse nichts nützen, oder?

deti wrote on 17. Dec 2011 at 17:04:


Würde mich nicht stören, denn es scheint derzeit die einzig sinnvolle Möglichkeit zu sein, eine man-in-the-middle-Attacke sicher auszuschließen.

deti wrote on 17. Dec 2011 at 17:04:


Das scheint mir eine Vertrauensfrage zu sein. Ich fühle mich erst dann einigermaßen sicher, wenn ich in der Konfiguration überhaupt keinen Server eintragen muß. Es könnte ein ungewollter Bug in der Software existieren oder ich habe eine Fehlkonfiguration ohne es zu wissen und der Schlüsselaustausch läuft doch über den Server, der evtl. von Behörden kompromittiert ist.

Frohe Weihnachten!

Phoner Admin wrote on 29. Dec 2011 at 12:30:


Leider nicht. Ich habe sowohl bei mir als auch beim Angerufenen den Haken bei Register entfernt, bei Server nirgendwo etwas eingetragen, bei User nur den User name (wozu eigentlich?), Network auf TLS erzwingen gestellt, Port auf 5060 (5060-5063 both UDP and TCP forwarded, aber nur am router des angerufenen) und bei Codecs alle 5 Haken gesetzt.

Ich bekomme eine Verbindung (komischerweise ohne angenommen zu haben?), aber scheinbar ohne ZRTP: Certificate not valid for this domain.

Heißt das, daß das eingebaute Zertifikat nicht funktioniert? Aber warum nicht?

Also so richtig begriffen habe ich das mit den Zertifikaten bzw. der Verschlüsselung nicht. Mir liegt sehr daran, daß das Telefonat NICHT abgehört werden kann.

Wozu ist das eingebaute Zertifikat denn überhaupt fähig bzw. in welchem Fall funktioniert es ohne Fehlermeldung? Dient es lediglich dazu, eine Verbindung mittels TLS überhaupt aufzubauen, wenn auch definitiv mit der Meldung: Certificate not valid for this domain?

Das Telefonat ist dann also erstmal definitiv verschlüsselt und es ist lediglich noch die Möglichkeit eines "man in the middle" gegeben? Kann ich also diese letzte Angriffsmöglichkeit etwa ENTWEDER durch Zertifikate ODER ZRTP ausschließen? Oder benötige ich doch beides? Oder ist beides nicht sicherer als nur eine der beiden Möglichkeiten?

Ich glaube, jetzt habe ich es begriffen.

TLS ist lediglich zum verschluesselten Verbindungsaufbau. Mit dem eingebauten Zertifikat kann man allerdings keine "man in the middle"-Attacke ausschliessen. Mit einem eigenen Zertifikat allerdings schon, aber auch nur fuer den Verbindungsaufbau. Um die Sprache selbst zu verschluesseln kann ich entweder SRTP oder ZRTP hinzuschalten. ZRTP bietet mittels SAS zusaetzlich zu SRTP noch die Moeglichkeit, eine etwaige "men in the middle"-Attacke fuer die Datenuebertragung auszuschliessen.

Wenn das so stimmt, dann bleibt eigentlich nur noch die Frage, welchen Vorteil es hat, bei Verwendung von ZRTP zusaetzlich noch SRTP zu aktivieren?

Tja, also ich habe es eben versucht, aber ZRTP scheint nicht zu funktionieren. Lediglich SRTP. Wenn ich ZRTP erzwinge (nur dort den Haken), dann wird bis auf TLS gar nichts verschlüsselt.

Und weder ich höre den Angerufenen noch der Angerufene mich, obwohl die (SRTP-)Verbindung scheinbar steht.

Noch irgendwelche Ideen? Gibt es irgendwo eine detailierte Logfunktion? Hab ich irgendwas wichtiges für ZRTP vergessen?

Da ich eigentlich nicht mit Zertifikaten herumhantieren wollte, hatte ich mich eigentlich schon auf ZRTP festgelegt und nun funktioniert genau das überhaupt nicht.