Kleines Einmaleins der digitalen Selbstverteidigung – netzpolitik.org

Wie man die Datensammler im Internet in den Griff bekommt: Wir tragen hier einige Basics zum eigenen Schutz zusammen und nennen Alternativen zu den Diensten der großen Konzerne. Ein Überblick.

Quelle: Kleines Einmaleins der digitalen Selbstverteidigung – netzpolitik.org

Veröffentlicht unter Inside, Tipps | Hinterlasse einen Kommentar

Interview ǀ „Wir müssen den Reichtum abschaffen!“ — der Freitag

Ab wann ist man zu reich?

Acht Menschen besitzen das Gleiche wie die halbe Weltbevölkerung.
Dieses Ungleichgewicht bringt das soziale Gefüge der Welt in große Gefahr.

Von diesen Leuten werden Unsummen in Kriegsmaschinerie und asoziale Projekte investiert, nebenbei wird die Umwelt verpestet, Kriege vorangetrieben und durch manipulative Finanzaktionen werden wahlweise ruinöse oder wirtschaftfördernde Strukturen bereitet, während der Rest der Menschheit die Folgen ausbaden muss.

Interview ǀ „Wir müssen den Reichtum abschaffen!“ — der Freitag

Christian Neuhäuser denkt darüber nach, ab welcher Grenze Vermögen ein moralisches Problem wird

Quelle: Interview ǀ „Wir müssen den Reichtum abschaffen!“ — der Freitag

Veröffentlicht unter World-News | Hinterlasse einen Kommentar

JÖRN Jasper GOES Neumünster – Live im Schwalebräu

Kommet her in Scharen, Live im Schwalebräu Neumünster,
A little tribute to Johnny Cash,
Renditions, Covers, Loops and more…
Ich werde ein kleines Tribute to Johnny Cash in Original-Tonlage präsentieren und in weiteren zwei Sets andere Songs aus den vergangenen Jahrzehnten mit Liebe und Looper aufbereiten.
Kommt vorbei und lasset uns einen schönen Abend mit Live Musik haben. Ich freu mich drauf 😉 🙂

Hinterlasse einen Kommentar

Trinkwasser aus der Luft

Dieser Artikel ist bereits 9 Jahre alt. Inzwischen gibt es viele kleine private Entwicklungen, gross, klein, mit Windkraft usw. Allerdings, eine massive Förderung dieser Technologie seitens eines Staates konnte ich nicht finden … angesichts des Klimawandels, der Situation in Afrika ist eventuell ein Umdenken, besonders bei den Politikern nötig. Dauerhafte Hilfe zu etablieren anstatt Milliarden in Krieg zu stecken wäre eine gute Möglichkeit.

—–

So könnten die Anlagen aussehen, die in großen Mengen Trinkwasser aus der Luft generieren.

Kein Pflänzchen weit und breit – dafür ist es in der Wüste zu trocken. Doch in der Luft ist Wasser enthalten. Fraunhofer-Forscher haben nun einen Weg gefunden, aus der Luftfeuchtigkeit Trinkwasser zu gewinnen. Das System basiert nur auf regenerativer Energie und arbeitet daher vollkommen unabhängig.

Risse ziehen sich durch den ausgedörrten Wüstenboden – die karge Landschaft ist geprägt von Wassermangel. Doch selbst dort, wo es an Seen, Flüssen und Grundwasser mangelt, sind in der Luft erhebliche Wassermengen gespeichert: In der Negev-Wüste in Israel beispielsweise beträgt die relative Luftfeuchtigkeit im Jahresmittel 64 Prozent – in jedem Kubikmeter Luft befinden sich 11,5 Milliliter Wasser.

Salzlösung saugt Feuchtigkeit auf

Forscher des Fraunhofer-Instituts für Grenzflächen- und Bioverfahrenstechnik IGB in Stuttgart haben gemeinsam mit ihren Kollegen von der Firma Logos Innovationen einen Weg gefunden, diese Luftfeuchtigkeit autark und dezentral in trinkbares Wasser umzuwandeln.

„Der Prozess, den wir entwickelt haben, basiert ausschließlich auf regenerativen Energiequellen wie einfachen thermischen Sonnenkollektoren und Photovoltaikzellen, was diese Methode vollständig energieautark macht. Sie funktioniert also auch in Gegenden, in denen es keine elektrische Infrastruktur gibt“, sagt Siegfried Egner vom IGB.

Das Prinzip: So genannte hygroskopische Salzsole – also Salzlösung, die Feuchtigkeit aufsaugt – rinnt an einer turmförmigen Anlage hinunter und nimmt Wasser aus der Luft auf. Anschließend wird sie in einen Behälter gepumpt, der in einigen Metern Höhe steht und in dem Vakuum herrscht.

Sonnenenergie erwärmt Sole

Energie aus Sonnenkollektoren erwärmt die Sole, die durch das aufgenommene Wasser verdünnt ist. Der Siedepunkt liegt aufgrund des Vakuums niedriger als bei normalem Luftdruck. Diesen Effekt kennt man aus den Bergen: Da der Luftdruck auf dem Gipfel geringer ist als im Tal, kocht Wasser bereits bei Temperaturen deutlich unter 100 Grad Celsius.

Das verdampfte, salzfreie Wasser kondensiert über eine Destillationsbrücke und läuft über ein vollständig gefülltes Rohr kontrolliert nach unten ab, wobei die Schwerkraft dieser Wassersäule kontinuierlich das Vakuum erzeugt – eine Vakuumpumpe ist nicht nötig. Die wieder konzentrierte Salzsole fließt erneut an der Turmoberfläche hinunter, um erneut Luftfeuchtigkeit aufzunehmen.

 

Nächstes Ziel: Demonstrationsanlage

„Das Konzept eignet sich für verschiedene Größenordnungen: Es sind sowohl Einzelpersonenanlagen denkbar als auch Anlagen, die ganze Hotels mit Wasser versorgen“, sagt Egner. Für beide Komponenten, die Aufnahme der Luftfeuchtigkeit und die Vakuumverdampfung, gibt es Prototypen. In Laborversuchen haben die Forscher das Zusammenspiel der beiden Komponenten bereits getestet. In einem weiteren Schritt wollen sie nun eine Demonstrationsanlage entwickeln.

Quelle: Neue Methode nutzt regenerative Energien zur Wasserproduktion Trinkwasser aus der Luft – scinexx | Das Wissensmagazin

Veröffentlicht unter World-News | Hinterlasse einen Kommentar

Miniatur Wunderland

FREIER EINTRITT ins Miniatur Wunderland für alle, die sich das nicht leisten können!!! BITTE TEILEN, damit viele es erfahren!

Das Wunderland hat auch im 16. Jahr in Folge mit über 1,4 Mio Besuchern einen Besucherrekord aufgestellt. Grund für uns mal wieder innezuhalten und sich umzuschauen. Leider ist es im letzten Jahr nicht allen Menschen so gut ergangen. Es gibt so viele Familien, für die ein Kino-, Theater- oder Wunderland-Besuch schlicht zu teuer ist.

All diesen Menschen möchten wir ein wenig Freude schenken und an einen von 22 ausgewählten Terminen im Januar zu uns ins Wunderland einladen.

Aber wer kann sich einen Wunderland-Besuch nicht leisten? Wir möchten die Menschen nicht in Kategorien einteilen, sondern machen das ganz simpel: Jeder der wirklich der Meinung ist, dass er sich einen Wunderland-Besuch nicht leisten kann, braucht an den unten genannten Terminen im Januar nur an der Kasse in beliebiger Sprache „Ich kann mir das nicht leisten“ sagen und kommt umsonst ins Wunderland.

Wer es sich nicht traut, dass zu sagen, kann auch einfach einen Zettel hinlegen.

Wir bitten Euch alle diese Info ganz viel zu verbreiten, damit möglichst viele Menschen erreicht werden. Das Angebot gilt nicht nur für Hamburger, sondern alle. Vielleicht bilden sich ja Fahrgemeinschaften für Menschen die sich die Anfahrt nicht leisten können.

Und zuletzt ein ganz wichtiger Appell: Hier geht es um großes Vertrauen. Wir hoffen, dass es nicht missbraucht wird.
Fakten: (http://www.miniatur-wunderland.de/leisten)

WIE: Einfach an der Kasse sagen (oder Zettel), dass man sich das Ticket nicht leisten kann.

WO: Miniatur Wunderland – Kehrwieder 2 – 20457 Hamburg

WER: Jeder der sich wirklich einen Besuch nicht leisten kann, egal ob Sozialleistungsempfänger, Flüchtling, allein erziehende Mütter/ Väter, Obdachlose oder andere, die jeden Euro zwei Mal umdrehen müssen.

Termine:
Vorweg: Die vier Sonntage sind eigentlich zu voll für eine solche Aktion. Daher bitten wir jeden, der auch in der Woche kann, den Sonntag nicht zu wählen. Wer nur da kann: Es wird zu Wartezeiten von 20-80 Minuten kommen.
Generell gilt an allen Tagen, dass es nachmittags leerer ist als vormittags. Sie helfen uns bei der Verteilung der Gäste, wenn Sie nachmittags kommen.

Sonntag, 07. Januar 2018 (8:30-20 Uhr, sehr voll, bitte möglichst meiden)
Montag, 08. Januar 2018 (9:30-18 Uhr)
Dienstag, 09. Januar 2018 (9:30-21 Uhr)
Mittwoch, 10. Januar 2018 (9:30-18 Uhr)
Donnerstag, 11. Januar 2018 (9:30-18 Uhr)
Freitag, 12. Januar 2018 (9-19 Uhr)

Sonntag, 14. Januar 2018 (8:30-20 Uhr, sehr voll, bitte möglichst meiden)
Montag, 15. Januar 2018 (9-18 Uhr)
Dienstag, 16. Januar 2018 (9-21 Uhr)
Mittwoch, 17. Januar 2018 (9-18 Uhr)
Donnerstag, 18. Januar 2018 (9-18 Uhr)
Freitag, 19. Januar 2018 (9-19 Uhr)

Sonntag, 21. Januar 2018 (8-21 Uhr, sehr voll, bitte möglichst meiden)
Montag, 22. Januar 2018 (9-18 Uhr)
Dienstag, 23. Januar 2018 (9-21 Uhr)
Mittwoch, 24. Januar 2018 (9-19 Uhr)
Donnerstag, 25. Januar 2018 (9-19 Uhr)
Freitag, 26. Januar 2018 (9-19 Uhr)

Sonntag, 28. Januar 2018 (8-21 Uhr, sehr voll, bitte möglichst meiden)
Montag, 29. Januar 2018 (9-19 Uhr)
Dienstag, 30. Januar 2018 (9-21 Uhr)
Mittwoch, 31. Januar 2018 (9-19 Uhr)

Veröffentlicht unter Altona, Tipps | Kommentare deaktiviert für Miniatur Wunderland

Getting Started with WebRTC – HTML5 Rocks

WebRTC is a new front in the long war for an open and unencumbered web.Brendan Eich, inventor of JavaScript

Real-time communication without plugins

Imagine a world where your phone, TV and computer could all communicate on a common platform. Imagine it was easy to add video chat and peer-to-peer data sharing to your web application. That’s the vision of WebRTC.

Want to try it out? WebRTC is available now in Google Chrome, Opera and Firefox. A good place to start is the simple video chat application at apprtc.appspot.com:

  1. Open apprtc.appspot.com in Chrome, Opera or Firefox.
  2. Click the Allow button to let the app use your webcam.
  3. Open the URL displayed at the bottom of the page in a new tab or, better still, on a different computer.

There is a walkthrough of this application later in this article.

Quick start

Haven’t got time to read this article, or just want code?

  1. Get an overview of WebRTC from the Google I/O presentation (the slides are here):

  2. If you haven’t used getUserMedia, take a look at the HTML5 Rocks article on the subject, and view the source for the simple example at simpl.info/gum.
  3. Get to grips with the RTCPeerConnection API by reading through the simple example below and the demo at simpl.info/pc, which implements WebRTC on a single web page.
  4. Learn more about how WebRTC uses servers for signaling, and firewall and NAT traversal, by reading through the code and console logs from apprtc.appspot.com.
  5. Can’t wait and just want to try out WebRTC right now? Try out some of the 20+ demos that exercise the WebRTC JavaScript APIs.
  6. Having trouble with your machine and WebRTC? Try out our troubleshooting page test.webrtc.org.

Alternatively, jump straight into our WebRTC codelab: a step-by-step guide that explains how to build a complete video chat app, including a simple signaling server.

A very short history of WebRTC

One of the last major challenges for the web is to enable human communication via voice and video: Real Time Communication, RTC for short. RTC should be as natural in a web application as entering text in a text input. Without it, we’re limited in our ability to innovate and develop new ways for people to interact.

Historically, RTC has been corporate and complex, requiring expensive audio and video technologies to be licensed or developed in house. Integrating RTC technology with existing content, data and services has been difficult and time consuming, particularly on the web.

Gmail video chat became popular in 2008, and in 2011 Google introduced Hangouts, which use the Google Talk service (as does Gmail). Google bought GIPS, a company which had developed many components required for RTC, such as codecs and echo cancellation techniques. Google open sourced the technologies developed by GIPS and engaged with relevant standards bodies at the IETF and W3C to ensure industry consensus. In May 2011, Ericsson built the first implementation of WebRTC.

WebRTC has now implemented open standards for real-time, plugin-free video, audio and data communication. The need is real:

  • Many web services already use RTC, but need downloads, native apps or plugins. These includes Skype, Facebook (which uses Skype) and Google Hangouts (which use the Google Talk plugin).
  • Downloading, installing and updating plugins can be complex, error prone and annoying.
  • Plugins can be difficult to deploy, debug, troubleshoot, test and maintain—and may require licensing and integration with complex, expensive technology. It’s often difficult to persuade people to install plugins in the first place!

The guiding principles of the WebRTC project are that its APIs should be open source, free, standardized, built into web browsers and more efficient than existing technologies.

Where are we now?

WebRTC is used in various apps like WhatsApp, Facebook Messenger, appear.in and platforms such as TokBox. There is even an experimental WebRTC enabled iOS Browser named Bowser. WebRTC has also been integrated with WebKitGTK+and Qt native apps.

Microsoft added MediaCapture and Stream APIs to Edge.

WebRTC implements three APIs:

getUserMedia is available in Chrome, Opera, Firefox and Edge. Take a look at the cross-browser demo at demo and Chris Wilson’s amazing examples using getUserMedia as input for Web Audio.

RTCPeerConnection is in Chrome (on desktop and for Android), Opera (on desktop and in the latest Android Beta) and in Firefox. A word of explanation about the name: after several iterations, RTCPeerConnection is currently implemented by Chrome and Opera as webkitRTCPeerConnection and by Firefox as mozRTCPeerConnection. Other names and implementations have been deprecated. When the standards process has stabilized, the prefixes will be removed. There’s an ultra-simple demo of Chromium’s RTCPeerConnection implementation at GitHub and a great video chat application at apprtc.appspot.com. This app uses adapter.js, a JavaScript shim, maintained Google with help from the WebRTC community, that abstracts away browser differences and spec changes.

RTCDataChannel is supported by Chrome, Opera and Firefox. Check out one of the data channel demos at GitHub to see it in action.

A word of warning

Be skeptical of reports that a platform ’supports WebRTC‘. Often this actually just means that getUserMedia is supported, but not any of the other RTC components.

My first WebRTC

WebRTC applications need to do several things:

  • Get streaming audio, video or other data.
  • Get network information such as IP addresses and ports, and exchange this with other WebRTC clients (known as peers) to enable connection, even through NATs and firewalls.
  • Coordinate signaling communication to report errors and initiate or close sessions.
  • Exchange information about media and client capability, such as resolution and codecs.
  • Communicate streaming audio, video or data.

To acquire and communicate streaming data, WebRTC implements the following APIs:

  • MediaStream: get access to data streams, such as from the user’s camera and microphone.
  • RTCPeerConnection: audio or video calling, with facilities for encryption and bandwidth management.
  • RTCDataChannel: peer-to-peer communication of generic data.

(There is detailed discussion of the network and signaling aspects of WebRTC below.)

MediaStream (aka getUserMedia)

The MediaStream API represents synchronized streams of media. For example, a stream taken from camera and microphone input has synchronized video and audio tracks. (Don’t confuse MediaStream tracks with the <track> element, which is something entirely different.)

Probably the easiest way to understand MediaStream is to look at it in the wild:

  1. In Chrome or Opera, open the demo at https://webrtc.github.io/samples/src/content/getusermedia/gum.
  2. Open the console.
  3. Inspect the stream variable, which is in global scope.

Each MediaStream has an input, which might be a MediaStream generated by navigator.getUserMedia(), and an output, which might be passed to a video element or an RTCPeerConnection.

The getUserMedia() method takes three parameters:

  • constraints object.
  • A success callback which, if called, is passed a MediaStream.
  • A failure callback which, if called, is passed an error object.

Each MediaStream has a label, such as’Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ‘. An array of MediaStreamTracks is returned by the getAudioTracks() and getVideoTracks() methods.

For the https://webrtc.github.io/samples/src/content/getusermedia/gum. example, stream.getAudioTracks() returns an empty array (because there’s no audio) and, assuming a working webcam is connected, stream.getVideoTracks()returns an array of one MediaStreamTrack representing the stream from the webcam. Each MediaStreamTrack has a kind (‚video‘ or ‚audio‘), and a label (something like ‚FaceTime HD Camera (Built-in)‘), and represents one or more channels of either audio or video. In this case, there is only one video track and no audio, but it is easy to imagine use cases where there are more: for example, a chat application that gets streams from the front camera, rear camera, microphone, and a ’screenshared‘ application.

In Chrome or Opera, the URL.createObjectURL() method converts a MediaStream to a Blob URL which can be set as the src of a video element. (In Firefox and Opera, the src of the video can be set from the stream itself.) Since version M25, Chromium-based browsers (Chrome and Opera) allow audio data from getUserMedia to be passed to an audio or video element (but note that by default the media element will be muted in this case).

getUserMedia can also be used as an input node for the Web Audio API:

function gotStream(stream) {
    window.AudioContext = window.AudioContext || window.webkitAudioContext;
    var audioContext = new AudioContext();

    // Create an AudioNode from the stream
    var mediaStreamSource = audioContext.createMediaStreamSource(stream);

    // Connect it to destination to hear yourself
    // or any other node for processing!
    mediaStreamSource.connect(audioContext.destination);
}

navigator.getUserMedia({audio:true}, gotStream);

Chromium-based apps and extensions can also incorporate getUserMedia. Adding audioCapture and/or videoCapture permissions to the manifest enables permission to be requested and granted only once, on installation. Thereafter the user is not asked for permission for camera or microphone access.

Likewise on pages using HTTPS: permission only has to be granted once for for getUserMedia() (in Chrome at least). First time around, an Always Allow button is displayed in the browser’s infobar.

Also, Chrome will deprecate HTTP access for getUserMedia() at the end of 2015 due to it being classified as a Powerful feature. You can already see a warning when invoked on a HTTP page on Chrome M44.

The intention is eventually to enable a MediaStream for any streaming data source, not just a camera or microphone. This would enable streaming from disc, or from arbitrary data sources such as sensors or other inputs.

Note that getUserMedia() must be used on a server, not the local file system, otherwise a PERMISSION_DENIED: 1 error will be thrown.

getUserMedia() really comes to life in combination with other JavaScript APIs and libraries:

  • Webcam Toy is a photobooth app that uses WebGL to add weird and wonderful effects to photos which can be shared or saved locally.
  • FaceKat is a ‚face tracking‘ game built with headtrackr.js.
  • ASCII Camera uses the Canvas API to generate ASCII images.
ASCII image generated by idevelop.ro/ascii-camera
gUM ASCII art!

Constraints

Constraints have been implemented since Chrome, Firefox and Opera. These can be used to set values for video resolution for getUserMedia() and RTCPeerConnection addStream() calls. The intention is to implement support for other constraints such as aspect ratio, facing mode (front or back camera), frame rate, height and width, along with an applyConstraints() method.

There’s an example at https://webrtc.github.io/samples/src/content/getusermedia/resolution/.

One gotcha: getUserMedia constraints set in one browser tab affect constraints for all tabs opened subsequently. Setting a disallowed value for constraints gives a rather cryptic error message:

navigator.getUserMedia error:
NavigatorUserMediaError {code: 1, PERMISSION_DENIED: 1}

Screen and tab capture

Chrome apps also make it possible to share a live ‚video‘ of a single browser tab or the entire desktop via chrome.tabCapture and chrome.desktopCapture APIs. A desktop capture sample extension can be found in the WebRTC samples GitHub repository. For screencast, code and more information, see the HTML5 Rocks update: Screensharing with WebRTC.

It’s also possible to use screen capture as a MediaStream source in Chrome using the experimental chromeMediaSource constraint, as in this demo. Note that screen capture requires HTTPS and should only be used for development due to it being enabled via a command line flag as explaind in this discuss-webrtc post.

Signaling: session control, network and media information

WebRTC uses RTCPeerConnection to communicate streaming data between browsers (aka peers), but also needs a mechanism to coordinate communication and to send control messages, a process known as signaling. Signaling methods and protocols are not specified by WebRTC: signaling is not part of the RTCPeerConnection API.

Instead, WebRTC app developers can choose whatever messaging protocol they prefer, such as SIP or XMPP, and any appropriate duplex (two-way) communication channel. The apprtc.appspot.com example uses XHR and the Channel API as the signaling mechanism. The codelab we built uses Socket.iorunning on a Node server.

Signaling is used to exchange three types of information:

  • Session control messages: to initialize or close communication and report errors.
  • Network configuration: to the outside world, what’s my computer’s IP address and port?
  • Media capabilities: what codecs and resolutions can be handled by my browser and the browser it wants to communicate with?

The exchange of information via signaling must have completed successfully before peer-to-peer streaming can begin.

For example, imagine Alice wants to communicate with Bob. Here’s a code sample from the WebRTC W3C Working Draft, which shows the signaling process in action. The code assumes the existence of some signaling mechanism, created in the createSignalingChannel() method. Also note that on Chrome and Opera, RTCPeerConnection is currently prefixed.

var signalingChannel = createSignalingChannel();
var pc;
var configuration = ...;

// run start(true) to initiate a call
function start(isCaller) {
    pc = new RTCPeerConnection(configuration);

    // send any ice candidates to the other peer
    pc.onicecandidate = function (evt) {
        signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
    };

    // once remote stream arrives, show it in the remote video element
    pc.onaddstream = function (evt) {
        remoteView.src = URL.createObjectURL(evt.stream);
    };

    // get the local stream, show it in the local video element and send it
    navigator.getUserMedia({ "audio": true, "video": true }, function (stream) {
        selfView.src = URL.createObjectURL(stream);
        pc.addStream(stream);

        if (isCaller)
            pc.createOffer(gotDescription);
        else
            pc.createAnswer(pc.remoteDescription, gotDescription);

        function gotDescription(desc) {
            pc.setLocalDescription(desc);
            signalingChannel.send(JSON.stringify({ "sdp": desc }));
        }
    });
}

signalingChannel.onmessage = function (evt) {
    if (!pc)
        start(false);

    var signal = JSON.parse(evt.data);
    if (signal.sdp)
        pc.setRemoteDescription(new RTCSessionDescription(signal.sdp));
    else
        pc.addIceCandidate(new RTCIceCandidate(signal.candidate));
};

First up, Alice and Bob exchange network information. (The expression ‚finding candidates‘ refers to the process of finding network interfaces and ports using the ICE framework.)

  1. Alice creates an RTCPeerConnection object with an onicecandidatehandler.
  2. The handler is run when network candidates become available.
  3. Alice sends serialized candidate data to Bob, via whatever signaling channel they are using: WebSocket or some other mechanism.
  4. When Bob gets a candidate message from Alice, he calls addIceCandidate, to add the candidate to the remote peer description.

WebRTC clients (known as peers, aka Alice and Bob) also need to ascertain and exchange local and remote audio and video media information, such as resolution and codec capabilities. Signaling to exchange media configuration information proceeds by exchanging an offer and an answer using the Session Description Protocol (SDP):

  1. Alice runs the RTCPeerConnection createOffer() method. The callback argument of this is passed an RTCSessionDescription: Alice’s local session description.
  2. In the callback, Alice sets the local description using setLocalDescription() and then sends this session description to Bob via their signaling channel. Note that RTCPeerConnection won’t start gathering candidates until setLocalDescription() is called: this is codified in JSEP IETF draft.
  3. Bob sets the description Alice sent him as the remote description using setRemoteDescription().
  4. Bob runs the RTCPeerConnection createAnswer() method, passing it the remote description he got from Alice, so a local session can be generated that is compatible with hers. The createAnswer() callback is passed an RTCSessionDescription: Bob sets that as the local description and sends it to Alice.
  5. When Alice gets Bob’s session description, she sets that as the remote description with setRemoteDescription.
  6. Ping!

RTCSessionDescription objects are blobs that conform to the Session Description Protocol, SDP. Serialized, an SDP object looks like this:

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

The acquisition and exchange of network and media information can be done simultaneously, but both processes must have completed before audio and video streaming between peers can begin.

The offer/answer architecture described above is called JSEP, JavaScript Session Establishment Protocol. (There’s an excellent animation explaining the process of signaling and streaming in Ericsson’s demo video for its first WebRTC implementation.)

JSEP architecture diagram
JSEP architecture

Once the signaling process has completed successfully, data can be streamed directly peer to peer, between the caller and callee—or if that fails, via an intermediary relay server (more about that below). Streaming is the job of RTCPeerConnection.

RTCPeerConnection

RTCPeerConnection is the WebRTC component that handles stable and efficient communication of streaming data between peers.

Below is a WebRTC architecture diagram showing the role of RTCPeerConnection. As you will notice, the green parts are complex!

WebRTC architecture diagram
WebRTC architecture (from webrtc.org)

From a JavaScript perspective, the main thing to understand from this diagram is that RTCPeerConnection shields web developers from the myriad complexities that lurk beneath. The codecs and protocols used by WebRTC do a huge amount of work to make real-time communication possible, even over unreliable networks:

  • packet loss concealment
  • echo cancellation
  • bandwidth adaptivity
  • dynamic jitter buffering
  • automatic gain control
  • noise reduction and suppression
  • image ‚cleaning‘.

The W3C code above shows a simplified example of WebRTC from a signaling perspective. Below are walkthroughs of two working WebRTC applications: the first is a simple example to demonstrate RTCPeerConnection; the second is a fully operational video chat client.

RTCPeerConnection without servers

The code below is taken from the ’single page‘ WebRTC demo at https://webrtc.github.io/samples/src/content/peerconnection/pc1, which has local and remote RTCPeerConnection (and local and remote video) on one web page. This doesn’t constitute anything very useful—caller and callee are on the same page—but it does make the workings of the RTCPeerConnection API a little clearer, since the RTCPeerConnection objects on the page can exchange data and messages directly without having to use intermediary signaling mechanisms.

One gotcha: the optional second ‚constraints‘ parameter of the RTCPeerConnection() constructor is different from the constraints type used by getUserMedia(): see w3.org/TR/webrtc/#constraints for more information.

In this example, pc1 represents the local peer (caller) and pc2 represents the remote peer (callee).

Caller

  1. Create a new RTCPeerConnection and add the stream from getUserMedia():
    // servers is an optional config file (see TURN and STUN discussion below)
    pc1 = new webkitRTCPeerConnection(servers);
    // ...
    pc1.addStream(localStream);
  2. Create an offer and set it as the local description for pc1 and as the remote description for pc2. This can be done directly in the code without using signaling, because both caller and callee are on the same page:
    pc1.createOffer(gotDescription1);
    //...
    function gotDescription1(desc){
      pc1.setLocalDescription(desc);
      trace("Offer from pc1 \n" + desc.sdp);
      pc2.setRemoteDescription(desc);
      pc2.createAnswer(gotDescription2);
    }

Callee

  1. Create pc2 and, when the stream from pc1 is added, display it in a video element:
    pc2 = new webkitRTCPeerConnection(servers);
    pc2.onaddstream = gotRemoteStream;
    //...
    function gotRemoteStream(e){
      vid2.src = URL.createObjectURL(e.stream);
    }

RTCPeerConnection plus servers

In the real world, WebRTC needs servers, however simple, so the following can happen:

  • Users discover each other and exchange ‚real world‘ details such as names.
  • WebRTC client applications (peers) exchange network information.
  • Peers exchange data about media such as video format and resolution.
  • WebRTC client applications traverse NAT gateways and firewalls.

In other words, WebRTC needs four types of server-side functionality:

  • User discovery and communication.
  • Signaling.
  • NAT/firewall traversal.
  • Relay servers in case peer-to-peer communication fails.

NAT traversal, peer-to-peer networking, and the requirements for building a server app for user discovery and signaling, are beyond the scope of this article. Suffice to say that the STUN protocol and its extension TURN are used by the ICEframework to enable RTCPeerConnection to cope with NAT traversal and other network vagaries.

ICE is a framework for connecting peers, such as two video chat clients. Initially, ICE tries to connect peers directly, with the lowest possible latency, via UDP. In this process, STUN servers have a single task: to enable a peer behind a NAT to find out its public address and port. (Google has a couple of STUN severs, one of which is used in the apprtc.appspot.com example.)

Finding connection candidates
Finding connection candidates

If UDP fails, ICE tries TCP: first HTTP, then HTTPS. If direct connection fails—in particular, because of enterprise NAT traversal and firewalls—ICE uses an intermediary (relay) TURN server. In other words, ICE will first use STUN with UDP to directly connect peers and, if that fails, will fall back to a TURN relay server. The expression ‚finding candidates‘ refers to the process of finding network interfaces and ports.

WebRTC data pathways
WebRTC data pathways

WebRTC engineer Justin Uberti provides more information about ICE, STUN and TURN in the 2013 Google I/O WebRTC presentation. (The presentation slides give examples of TURN and STUN server implementations.)

A simple video chat client

The walkthrough below describes the signaling mechanism used by apprtc.appspot.com.

If you find this somewhat baffling, you may prefer our WebRTC codelab. This step-by-step guide explains how to build a complete video chat application, including a simple signaling server built with Socket.io running on a Node server.

A good place to try out WebRTC, complete with signaling and NAT/firewall traversal using a STUN server, is the video chat demo at apprtc.appspot.com. This app uses adapter.js to cope with different RTCPeerConnection and getUserMedia() implementations.

The code is deliberately verbose in its logging: check the console to understand the order of events. Below we give a detailed walk-through of the code.

What’s going on?

The demo starts by running the initialize() function:

function initialize() {
    console.log("Initializing; room=99688636.");
    card = document.getElementById("card");
    localVideo = document.getElementById("localVideo");
    miniVideo = document.getElementById("miniVideo");
    remoteVideo = document.getElementById("remoteVideo");
    resetStatus();
    openChannel('AHRlWrqvgCpvbd9B-Gl5vZ2F1BlpwFv0xBUwRgLF/* ...*/');
    doGetUserMedia();
  }

Note that values such as the room variable and the token used by openChannel(), are provided by the Google App Engine app itself: take a look at the index.html template in the repository to see what values are added.

This code initializes variables for the HTML video elements that will display video streams from the local camera (localVideo) and from the camera on the remote client (remoteVideo). resetStatus() simply sets a status message.

The openChannel() function sets up messaging between WebRTC clients:

function openChannel(channelToken) {
  console.log("Opening channel.");
  var channel = new goog.appengine.Channel(channelToken);
  var handler = {
    'onopen': onChannelOpened,
    'onmessage': onChannelMessage,
    'onerror': onChannelError,
    'onclose': onChannelClosed
  };
  socket = channel.open(handler);
}

For signaling, this demo uses the Google App Engine Channel API, which enables messaging between JavaScript clients without polling. (WebRTC signaling is covered in more detail above).

Architecture of the apprtc video chat application
Architecture of the apprtc video chat application

Establishing a channel with the Channel API works like this:

  1. Client A generates a unique ID.
  2. Client A requests a Channel token from the App Engine app, passing its ID.
  3. App Engine app requests a channel and a token for the client’s ID from the Channel API.
  4. App sends the token to Client A.
  5. Client A opens a socket and listens on the channel set up on the server.
The Google Channel API: establishing a channel
The Google Channel API: establishing a channel

Sending a message works like this:

  1. Client B makes a POST request to the App Engine app with an update.
  2. The App Engine app passes a request to the channel.
  3. The channel carries a message to Client A.
  4. Client A’s onmessage callback is called.
The Google Channel API: sending a message
The Google Channel API: sending a message

Just to reiterate: signaling messages are communicated via whatever mechanism the developer chooses: the signaling mechanism is not specified by WebRTC. The Channel API is used in this demo, but other methods (such as WebSocket) could be used instead.

After the call to openChannel(), the getUserMedia() function called by initialize() checks if the browser supports the getUserMedia API. (Find out more about getUserMedia on HTML5 Rocks.) If all is well, onUserMediaSuccess is called:

function onUserMediaSuccess(stream) {
  console.log("User has granted access to local media.");
  // Call the polyfill wrapper to attach the media stream to this element.
  attachMediaStream(localVideo, stream);
  localVideo.style.opacity = 1;
  localStream = stream;
  // Caller creates PeerConnection.
  if (initiator) maybeStart();
}

This causes video from the local camera to be displayed in the localVideoelement, by creating an object (Blob) URL for the camera’s data stream and then setting that URL as the src for the element. (createObjectURL is used here as a way to get a URI for an ‚in memory‘ binary resource, i.e. the LocalDataStream for the video.) The data stream is also set as the value of localStream, which is subsequently made available to the remote user.

At this point, initiator has been set to 1 (and it stays that way until the caller’s session has terminated) so maybeStart() is called:

function maybeStart() {
  if (!started && localStream && channelReady) {
    // ...
    createPeerConnection();
    // ...
    pc.addStream(localStream);
    started = true;
    // Caller initiates offer to peer.
    if (initiator)
      doCall();
  }
}

This function uses a handy construct when working with multiple asynchronous callbacks: maybeStart() may be called by any one of several functions, but the code in it is run only when localStream has been defined and channelReady has been set to true and communication hasn’t already started. So—if a connection hasn’t already been made, and a local stream is available, and a channel is ready for signaling, a connection is created and passed the local video stream. Once that happens, started is set to true, so a connection won’t be started more than once.

RTCPeerConnection: making a call

createPeerConnection(), called by maybeStart(), is where the real action begins:

function createPeerConnection() {
  var pc_config = {"iceServers": [{"url": "stun:stun.l.google.com:19302"}]};
  try {
    // Create an RTCPeerConnection via the polyfill (adapter.js).
    pc = new RTCPeerConnection(pc_config);
    pc.onicecandidate = onIceCandidate;
    console.log("Created RTCPeerConnnection with config:\n" + "  \"" +
      JSON.stringify(pc_config) + "\".");
  } catch (e) {
    console.log("Failed to create PeerConnection, exception: " + e.message);
    alert("Cannot create RTCPeerConnection object; WebRTC is not supported by this browser.");
      return;
  }

  pc.onconnecting = onSessionConnecting;
  pc.onopen = onSessionOpened;
  pc.onaddstream = onRemoteStreamAdded;
  pc.onremovestream = onRemoteStreamRemoved;
}

The underlying purpose is to set up a connection, using a STUN server, with onIceCandidate() as the callback (see above for an explanation of ICE, STUN and ‚candidate‘). Handlers are then set for each of the RTCPeerConnection events: when a session is connecting or open, and when a remote stream is added or removed. In fact, in this example these handlers only log status messages—except for onRemoteStreamAdded(), which sets the source for the remoteVideoelement:

function onRemoteStreamAdded(event) {
  // ...
  miniVideo.src = localVideo.src;
  attachMediaStream(remoteVideo, event.stream);
  remoteStream = event.stream;
  waitForRemoteVideo();
}

Once createPeerConnection() has been invoked in maybeStart(), a call is intitiated by creating and offer and sending it to the callee:

function doCall() {
  console.log("Sending offer to peer.");
  pc.createOffer(setLocalAndSendMessage, null, mediaConstraints);
}

The offer creation process here is similar to the no-signaling example above but, in addition, a message is sent to the remote peer, giving a serialized SessionDescription for the offer. This process is handled by setLocalAndSendMessage():

function setLocalAndSendMessage(sessionDescription) {
  // Set Opus as the preferred codec in SDP if Opus is present.
  sessionDescription.sdp = preferOpus(sessionDescription.sdp);
  pc.setLocalDescription(sessionDescription);
  sendMessage(sessionDescription);
}

Signaling with the Channel API

The onIceCandidate() callback invoked when the RTCPeerConnection is successfully created in createPeerConnection() sends information about candidates as they are ‚gathered‘:

function onIceCandidate(event) {
    if (event.candidate) {
      sendMessage({type: 'candidate',
        label: event.candidate.sdpMLineIndex,
        id: event.candidate.sdpMid,
        candidate: event.candidate.candidate});
    } else {
      console.log("End of candidates.");
    }
  }

Outbound messaging, from the client to the server, is done by sendMessage()with an XHR request:

function sendMessage(message) {
  var msgString = JSON.stringify(message);
  console.log('C->S: ' + msgString);
  path = '/message?r=99688636' + '&u=92246248';
  var xhr = new XMLHttpRequest();
  xhr.open('POST', path, true);
  xhr.send(msgString);
}

XHR works fine for sending signaling messages from the client to the server, but some mechanism is needed for server-to-client messaging: this application uses the Google App Engine Channel API. Messages from the API (i.e. from the App Engine server) are handled by processSignalingMessage():

function processSignalingMessage(message) {
  var msg = JSON.parse(message);

  if (msg.type === 'offer') {
    // Callee creates PeerConnection
    if (!initiator && !started)
      maybeStart();

    pc.setRemoteDescription(new RTCSessionDescription(msg));
    doAnswer();
  } else if (msg.type === 'answer' && started) {
    pc.setRemoteDescription(new RTCSessionDescription(msg));
  } else if (msg.type === 'candidate' && started) {
    var candidate = new RTCIceCandidate({sdpMLineIndex:msg.label,
                                         candidate:msg.candidate});
    pc.addIceCandidate(candidate);
  } else if (msg.type === 'bye' && started) {
    onRemoteHangup();
  }
}

If the message is an answer from a peer (a response to an offer), RTCPeerConnection sets the remote SessionDescription and communication can begin. If the message is an offer (i.e. a message from the callee) RTCPeerConnection sets the remote SessionDescription, sends an answer to the callee, and starts connection by invoking the RTCPeerConnection startIce()method:

function doAnswer() {
  console.log("Sending answer to peer.");
  pc.createAnswer(setLocalAndSendMessage, null, mediaConstraints);
}

And that’s it! The caller and callee have discovered each other and exchanged information about their capabilities, a call session is initiated, and real-time data communication can begin.

Network topologies

WebRTC as currently implemented only supports one-to-one communication, but could be used in more complex network scenarios: for example, with multiple peers each communicating each other directly, peer-to-peer, or via a Multipoint Control Unit (MCU), a server that can handle large numbers of participants and do selective stream forwarding, and mixing or recording of audio and video:

Multipoint Control Unit topology diagram
Multipoint Control Unit topology example

Many existing WebRTC apps only demonstrate communication between web browsers, but gateway servers can enable a WebRTC app running on a browser to interact with devices such as telephones (aka PSTN) and with VOIP systems. In May 2012, Doubango Telecom open-sourced the sipml5 SIP client, built with WebRTC and WebSocket which (among other potential uses) enables video calls between browsers and apps running on iOS or Android. At Google I/O, Tethr and Tropo demonstrated a framework for disaster communications ‚in a briefcase‘, using an OpenBTS cell to enable communications between feature phones and computers via WebRTC. Telephone communication without a carrier!

Tethr/Tropo demo at Google I/O 2012
Tethr/Tropo: disaster communications in a briefcase

RTCDataChannel

As well as audio and video, WebRTC supports real-time communication for other types of data.

The RTCDataChannel API enables peer-to-peer exchange of arbitrary data, with low latency and high throughput. There’s a simple ’single page‘ demo at http://webrtc.github.io/samples/src/content/datachannel/datatransfer.

There are many potential use cases for the API, including:

  • Gaming
  • Remote desktop applications
  • Real-time text chat
  • File transfer
  • Decentralized networks

The API has several features to make the most of RTCPeerConnection and enable powerful and flexible peer-to-peer communication:

  • Leveraging of RTCPeerConnection session setup.
  • Multiple simultaneous channels, with prioritization.
  • Reliable and unreliable delivery semantics.
  • Built-in security (DTLS) and congestion control.
  • Ability to use with or without audio or video.

The syntax is deliberately similar to WebSocket, with a send() method and a message event:

var pc = new webkitRTCPeerConnection(servers,
  {optional: [{RtpDataChannels: true}]});

pc.ondatachannel = function(event) {
  receiveChannel = event.channel;
  receiveChannel.onmessage = function(event){
    document.querySelector("div#receive").innerHTML = event.data;
  };
};

sendChannel = pc.createDataChannel("sendDataChannel", {reliable: false});

document.querySelector("button#send").onclick = function (){
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};

Communication occurs directly between browsers, so RTCDataChannel can be much faster than WebSocket even if a relay (TURN) server is required when ‚hole punching‘ to cope with firewalls and NATs fails.

RTCDataChannel is available in Chrome, Opera and Firefox. The magnificent Cube Slam game uses the API to communicate game state: play a friend or play the bear! Sharefest enables file sharing via RTCDataChannel, and peerCDN offers a glimpse of how WebRTC could enable peer-to-peer content distribution.

For more information about RTCDataChannel, take a look at the IETF’s draft protocol spec.

Security

There are several ways a real-time communication application or plugin might compromise security. For example:

  • Unencrypted media or data might be intercepted en route between browsers, or between a browser and a server.
  • An application might record and distribute video or audio without the user knowing.
  • Malware or viruses might be installed alongside an apparently innocuous plugin or application.

WebRTC has several features to avoid these problems:

  • WebRTC implementations use secure protocols such as DTLS and SRTP.
  • Encryption is mandatory for all WebRTC components, including signaling mechanisms.
  • WebRTC is not a plugin: its components run in the browser sandbox and not in a separate process, components do not require separate installation, and are updated whenever the browser is updated.
  • Camera and microphone access must be granted explicitly and, when the camera or microphone are running, this is clearly shown by the user interface.

A full discussion of security for streaming media is out of scope for this article. For more information, see the WebRTC Security Architecture proposed by the IETF.

In conclusion

The APIs and standards of WebRTC can democratize and decentralize tools for content creation and communication—for telephony, gaming, video production, music making, news gathering and many other applications.

Technology doesn’t get much more disruptive than this.

We look forward to what JavaScript developers make of WebRTC as it becomes widely implemented. As blogger Phil Edholm put it, ‚Potentially, WebRTC and HTML5 could enable the same transformation for real-time communications that the original browser did for information.‘

Developer tools

Learn more

Standards and protocols

WebRTC support summary

MediaStream and getUserMedia

  • Chrome desktop 18.0.1008+; Chrome for Android 29+
  • Opera 18+; Opera for Android 20+
  • Opera 12, Opera Mobile 12 (based on the Presto engine)
  • Firefox 17+
  • Microsoft Edge

RTCPeerConnection

  • Chrome desktop 20+ (now ‚flagless‘, i.e. no need to set about:flags); Chrome for Android 29+ (flagless)
  • Opera 18+ (on by default); Opera for Android 20+ (on by default)
  • Firefox 22+ (on by default)

RTCDataChannel

  • Experimental version in Chrome 25, more stable (and with Firefox interoperability) in Chrome 26+; Chrome for Android 29+
  • Stable version (and with Firefox interoperability) in Opera 18+; Opera for Android 20+
  • Firefox 22+ (on by default)

Native APIs for RTCPeerConnection are also available: documentation on webrtc.org.

For more detailed information about cross-platform support for APIs such as getUserMedia, see caniuse.com.

Quelle: Getting Started with WebRTC – HTML5 Rocks

Veröffentlicht unter Inside | Kommentare deaktiviert für Getting Started with WebRTC – HTML5 Rocks

Openfire Meetings – eigenen WebRTC Server einrichten und verwenden | ITrig

Openfire Meetings – eigenen WebRTC Server einrichten und verwenden

Vor einiger Zeit hatte ich einem Artikel über Jitsi Meet geschrieben. Es ging darum einen eigenen WebRTC Server für  Video und Audio Chats aufzusetzen.
Die Entwickler rund um das Jitsi Projekt sind mit ihrer Lösung schon lange nicht mehr alleine, auch andere verwenden diese Module um Videochats zu implementieren, so auch der XMPP Messaging Server Openfire.

Openfire Meetings – Videochats für den XMPP Server einrichten

Openfire ist ein XMPP Server mit einfach konfigurierbarer Oberfläche, der neben dem Bereitstellen einer klassischen Jabber Chat Umgebung durch diverse Plugins erweitert werden kann.

So kann der Server mit dem Openfire Meetings Plugin zu einem Web-RTC Server ausgebaut werden. Dieses basiert auf Jitsi Videobridge und bietet somit ähnliche Funktionalitäten wie der oben erwähnte Jitsi Meet Server.

Openfire auf Ubuntu installieren

Die Installation des Openfire Server sei hier noch einmal erwähnt, auch wenn sie bereits verblogt wurde.

wget -O openfire_3.10.2_all.deb „http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3.10.2_all.deb“

sudo dpkg -i openfire_3.10.2_all.deb

service openfire restart

Der installierte Server kann unter http://meinServer:9090 oder unterhttps://meinServer:9091 aufgerufen werden.

Openfire Meeting Plugin installieren

Das nötige Plugin für interaktive Meetings wird einfach über das integrierte Menü „Plugins/Available Plugins“ installiert. Danach ist es als eigener Menüpunkt in Openfire zu finden.

openfire-_Available-Plugins

Nach der Installation sollte in den Einstellungen unter „Mettings Settings“ eine IP hinterlegt werden.
Umgebungen, die hinter einer Firewall eingerichtet werden, sollten zwingend die in der Konfiguration angegebenen Ports freischalten.

openfire-meeting-plugin

Openfire Meetings Chrome Erweiterung installieren

Die Openfire Meetings Browser Erweiterung, welche zurzeit nur für Chrome zur Verfügung steht, erweitert Videochats um Funktionen wie Bildschirmteilen oder Anwendungsaustausch. Die Installation erfolgt über den Chrome Webstore

openfire-chrome

Weitere nützliche Openfire Plugins

Damit der Server sich auf Gruppenchats und URL Lesezeichen versteht, kann das Client Control Plugin installiert werden. Wie der Name vermuten lässt können damit auch die erlaubten Clients im Netz reguliert werden. URL Lesezeichen bieten sich an, um eine Meetings URL im Client direkt zu hinterlegen.

Das Fastpath Plugin ist ebenfalls eine praktische Erweiterung, um den bestehenden Server für Arbeitsgruppen auszubauen.

Für eine schnelle Nutzerumbennenung empfiehlt sich just married.

Die hier erwähnten Plugins sind für einen WebRTC Server Betrieb nicht notwendig, sondern optional.

Meeting erstellen oder beitreten

Nachdem alle Module erfolgreich installiert wurden, lässt sich der Meeting Server unter  https://meinServer:7443/ofmeet aufrufen.

Diejenigen welche sich bereits mit Jitsi Meet auseinander gesetzt haben, werden die Oberfläche bereits kennen.

ofmeet

Bestehende Räume lassen sich mit der im Vorfeld generierten ID direkt aufrufen https://meinServer:7443/ofmeet/?r=xxxxx. 

Zusätzlich besteht die Möglichkeit eine Videoübertragung von vornherein auszuschließen, hierzu muss die URL wie folgt manipuliert werden https://meinServer:7443/ofmeet/?r=xxxxx&novideo=true

Inzwischen sind weitere Funktionen wie ein Kalender mit Email Benachrichtigung verfügbar, auch ein normaler Gruppenchat mit Candy (Chats are not dead yet) ist möglich. Weitere Details dazu können auf der Openfire Meeting Seite direkt nachgelesen werden.

Fazit

Ähnlich wie Jitsi Meet stellt Openfire eine fertige Videochat Lösung bereit. Sie lässt sich einfach in eine bestehende Jabber/Xmpp Server Struktur einbinden. dank der Installation via Plugin sind keine weiteren Konfigurationen notwendig, sieht man einmal von einer eventuell vorhandenen Firewall ab. Die Kalender und Mailfunktion scheint praktisch zu sein, in meiner Teststellung konnte ich sie leider nicht testen.

Quelle: Openfire Meetings – eigenen WebRTC Server einrichten und verwenden | ITrig

Veröffentlicht unter Inside | Kommentare deaktiviert für Openfire Meetings – eigenen WebRTC Server einrichten und verwenden | ITrig

LiMux-Aus: München erklärt neue Mail-Software für geheim | heise online

LiMux-Aus: München erklärt neue Mail-Software für geheim

  Stefan Krempl

Maskottchen LiMux vor dem Münchner Rathaus

(Bild: dpa, Peter Kneffel)

Die Stadt München beginnt im Oktober mit der Umstellung auf eine neue Groupware, zunächst wird das Mailsystem renoviert. Offenbar kommt aber nicht der Open-Source-Ausschreibungsgewinner Kolab zum Einsatz, sondern Microsoft Exchange.

Seit vielen Jahren warten die Mitarbeiter der Münchner Stadtverwaltung auf ein integriertes E-Mail- und Kalendersystem. Im Oktober will der IT-Dienstleister der Landeshauptstadt IT@M nun endlich damit beginnen, eine entsprechende Groupware einzuführen und in einem ersten Schritt den bisherigen Open-Source-Mailclient Thunderbird auf eine neue Plattform umstellen. Im Anschluss soll auch die sich derzeit noch im Einsatz befindliche Kalenderlösung von Oracle ausgetauscht werden. Dies geht aus einer „Projektbeschreibung“ hervor, die heise online vorliegt.

Linux-Betriebssystem für Kommunen

LiMux – Linux in der Stadtverwaltung München

Als erste deutsche Großstadt stellte München die rund 15.000 städtischen Computer von Windows auf Linux um. Das Vorzeigeprojekt für Linux und Open Source in der Stadtverwaltung war lange umstritten, besonders Microsoft machte intensive Lobby-Arbeit dagegen. Auch nach der Einführung geriet LiMux immer wieder unter Beschuss.

„Die bisherigen Anwendungen sind seit etwa 15 Jahren bei der Landeshauptstadt München im Einsatz und werden von den Herstellern nicht mehr weiterentwickelt und nur noch eingeschränkt oder gar nicht mehr betreut“, heißt es in der entsprechenden elektronischen Notiz. Von einem Support-Aus für Thunderbird kann zwar keine Rede sein. Dennoch ist in der Projektskizze zu lesen, dass bei den in München bislang verwendeten Lösungen „vermehrt Fehler auftreten, die nicht mehr behoben werden können“. Zudem seien getrennte Programme für E-Post und Terminverwaltung „heute nicht mehr zeitgemäß“.

Die neue Groupware solle daher künftig an rund 16.000 Büroarbeitsplätzen für circa 40.000 städtische Arbeitskräfte einheitlich zur Verfügung stehen, versprechen die Koordinatoren des Projekts „MigMak“, was für „Migration Mail- und Kalender-System“ steht. Seit über drei Jahren hat IT@M zusammen mit Partnern daran gearbeitet. Auf eine öffentliche Ausschreibung hin hatte im Februar 2014 ein Dreierkonsortium den Zuschlag erhalten, das aus dem lokalen Systemhaus ESG, dem Bremer E-Learning-Unternehmen Szenaris sowie dem Schweizer Groupware-Spezialisten Kolab Systems bestand. Der Auftrag lautete, das damalige Open-Source-Vorzeigeprojekt LiMux mit einer integrierten Mail- und Kalenderlösung auszustatten.

Im Herbst 2014 erklärte der Münchner IT-Beauftragte Robert Kotulek noch gegenüber c’t, dass Thunderbird und der Oracle-Kalender im Jahr 2015 durch ein neues System auf Basis von Kolab ersetzt würden. Fast parallel meldete Kolab-Gründer Georg Greve größere Fortschritte bei der Lösung. Der Desktop-Client werde mit einem damals geplanten LiMux-Update einsatzbereit sein. Es sollte dem Vernehmen nach aber noch gut zwei Jahre dauern, bis zunächst die Mail-Software die Tests bestanden hatte und in der Fläche zur Verfügung stand.

Dazwischen kam nicht nur der immer lauter werdende Unmut in der neuen Rathausspitze gegenüber LiMux, das beim Oberbürgermeister Dieter Reiter (SPD) und seinem Vize Josef Schmid (CSU) rasch in Ungnade gefallen war. Im Februar stimmte der Münchner Stadtrat mit seiner schwarz-roten Mehrheit zudem prinzipiell dafür, bis Ende 2020 einen neuen Windows-Basis-Client für die Verwaltung zu entwickeln und die vorhandene Open-Source-Alternative auszumustern. Für die IT-Dienstleister war das offenbar ein Wink mit dem Zaunpfahl, auch von der quelloffenen Groupware Abstand zu nehmen und bei MigMak entgegen bisheriger Kriterien auf die Microsoft-Lösung Exchange umzusatteln.

Der IT@M-Leiter Karl-Heinz Schneider hatte nach ersten entsprechenden Gerüchten im April gegenüber heise online allgemein ausgeführt, dass „für die Ablösung der Serverseite alle Produkte betrachtet werden, die die Größe und Anforderungsvielfalt der Landeshauptstadt München unterstützen können“. Dazu gehöre auch das einschlägige Microsoft-System Exchange, das mit Outlook zusammenspielt.

Auf eine aktuelle Nachfrage, welches Programm nun im Oktober ausgerollt werde, bat Schneider um Verständnis dafür, „dass wir zu Produkten, die bei uns im Einsatz sind, keine Auskunft geben“. Dies gelte „ganz besonders für alle Komponenten, die in sicherheitsrelevanten Aufgaben eingesetzt werden, wozu auch unser E-Mail-System zählt“. Mit der Linux-Windows-Diskussion habe dies nichts zu tun.

LiMux-Aus: München erklärt neue Mail-Software für geheim
Bildschirmfoto der Projektpräsentation

Mit anderen Worten: Die neue Groupware-Lösung soll geheim bleiben, um angeblich Hackern weniger Angriffsfläche zu bieten. Sicherheitsexperten halten von solchen Verschleierungsversuchen freilich wenig, da damit kein Vertrauen geschaffen werden könne. Die Grünen im Stadtrat wollten zudem schon im Juni nach den ersten WannaCry-Attacken vom Oberbürgermeister wissen, wie sich die IT-Gefährdungslage verändere, wenn die Stadt eine Rückkehr zu Microsoft-Produkten auf den Weg bringe. 2014 hatte die Rathausspitze eingeräumt, „dass im Microsoft-Umfeld ein höheres Potenzial für Bedrohungen“ bestehe als bei freier Software.

Vieles spricht dafür, dass es sich bei dem nun angekündigten, offiziell nicht näher bezeichneten Mail- und Kalendersystem um Microsoft Exchange handelt. Ein Bildschirmfoto der einschlägigen Projektpräsentation weist im Design haargenaue Ähnlichkeiten mit der Lösung der Redmonder auf. Aus dem Verwaltungsumfeld erfuhr heise online zudem, dass die Entscheidung für Exchange schon vor einigen Monaten gefallen sei und jetzt rasch Nägel mit Köpfen gemacht würden.

Sollte dem so sein, käme neben Kostenaspekten vor allem die Frage auf, wieso IT@M den ursprünglichen Anforderungskatalog für MigMak anscheinend größtenteils verworfen, trotzdem aber keine neue öffentliche Ausschreibung durchgeführt und die ursprünglichen Gewinner abgesägt hat. Damit könnten die Münchner Probleme etwa mit der EU-Wettbewerbsbehörde bekommen.

Der Präsident der Free Software Foundation Europe (FSFE), Matthias Kirschner, ist auf jeden Fall besorgt. „In der Stadtratsitzung im Februar hat Oberbürgermeister Reiter noch gesagt, dass die Rückmigration nur geprüft werden soll“, erklärte er gegenüber heise online. Es sei vereinbart worden, dass der Stadtrat letztlich die Entscheidung nach einer bislang ausstehenden Kostenprüfung fallen werde. „Nach den uns vorliegenden Informationen werden allerdings schon konkrete Fakten geschaffen, sodass die Abstimmung im Stadtrat zu einer reinen Farce degradiert wird“, meint Kirschner. „So ein Verhalten ist natürlich Wind auf die Mühlen von Demokratiegegnern.“ (kbe)

Quelle: LiMux-Aus: München erklärt neue Mail-Software für geheim | heise online

Veröffentlicht unter World-News | 1 Kommentar

Bestes Angebot PC

Preiswerte PC’s & mehr für Geringverdiener

Wir geben gebrauchte Computer zum Selbstkostenpreis
an Menschen mit geringem Einkommen ab.

Alle Geräte und Einzelteile sind gebraucht und auf Funktionsfähigkeit geprüft. Wir bieten eine 12-monatige Gewährleistung auf gleichwertige Produkte.Der Computer ist für den alltäglichen Gebrauch gut gerüstet, jedoch nicht für moderne Computerspiele !*Dieses Angebot richtet sich ausschließlich an bedürftige Menschen, das heißt Bezieher von ALG II, Grundsicherung, Geringverdiener und Rentner mit einem Einkommen unterhalb des Pfändungsfreibetrages von 1.079,00€. Entsprechende Nachweise bitte beim Kauf vorlegen.Mook wat PC
Elsässer Straße 4
22049 Hamburg-DulsbergTel.: 040 / 65 86 53 53

Montag – Donnerstag :     8.30 – 11.30 Uhr und 12.30 – 14.30 Uhr
Freitag :                              8.30 – 11.30 Uhr (nicht nachmittags)

icon-car.pngKML-LogoFullscreen-LogoGeoJSON-LogoGeoRSS-Logo
Mook Wat PC

Karte wird geladen - bitte warten...

Mook Wat PC 53.579300, 10.063800
Veröffentlicht unter Tipps | 4 Kommentare

Geheime Dokumente: Der BND hat das Anonymisierungs-Netzwerk Tor angegriffen und warnt vor dessen Nutzung – netzpolitik.org

Überwachung

Geheime Dokumente: Der BND hat das Anonymisierungs-Netzwerk Tor angegriffen und warnt vor dessen Nutzung

Der BND hat ein System zur Überwachung des Tor-Netzwerks entwickelt und Bundesbehörden gewarnt, dass dessen Anonymisierung „unwirksam“ ist. Das geht aus einer Reihe geheimer Dokumente hervor, die wir veröffentlichen. Der Geheimdienst gab einen Prototyp dieser Technik an die NSA, in Erwartung einer Gegenleistung.

Der BND zerhäckselt Tor. (Symbolbild) Public Domain Caroline Attwood

„Surfen, spielen, shoppen – zu Hause im Cyperspace“: Das Buch Internet für Dummies „begleitet Sie bei Ihren ersten Schritten in die große, weite Welt des Internets“, wirbt der Verlag. Auch der Bundesnachrichtendienst kauft sich 2005 dieses Buch, um „mal da reinzukommen“, in dieses Internet. So schildert es Diplom-Ingenieur Harald Fechner vor zwei Jahren im Bundestags-Untersuchungsausschuss.

Das ist eine kreative Auslegung der Wahrheit. Bis zu seinem Ruhestand im Juni 2009 ist Fechner immerhin Leiter der BND-Abteilung Technische Aufklärung und damit zuständig für die Internet-Überwachung im Geheimdienst. Über tausend Spione hören für ihn „internationale Kommunikationsströme und elektronische Medien“ ab – auf Funkwellen, Telefonkabeln und angezapften Glasfasern.

Geheime Hacker-Einheit im BND

Unter dem Kommando seiner „Abteilung TA“ arbeitet auch eine geheime Hacker-Einheit, zuständig für „technisch-operative Angriffe auf IT-Einrichtungen“ in der ganzen Welt. Wie alles beim Geheimdienst wechseln die Hacker in der Pullacher Zentrale ständig ihre Bezeichnung: Bis August 2008 heißen sie „Referat 26E“ (Operative Unterstützung und Lauschtechnik), dann „Arbeitsgruppe TX“ (Informationstechnische Operationen) und seitdem „Unterabteilung T4“ (Cyber-Intelligence).

Innerhalb des Geheimdiensts erlangen die Hacker 2007 Bekanntheit. Einer von ihnen überwacht Liebes-E-Mails seiner Freundin mit einem Bundeswehr-Soldaten, dieser sogenannte LOVEINT-Vorfall macht intern die Runde. An die Öffentlichkeit kommt die Hacker-Einheit ein Jahr später, als auffliegt, dass sie das Netzwerk des afghanischen Handelsministeriums infiltriert hat. Dabei lesen die Spione nicht nur E-Mails des befreundeten Ministers mit, sondern auch von der Spiegel-Journalistin Susanne Koelbl.

Daran erinnert sich Harald Fechner noch genau, der Hacker-Angriff auf die Journalistin ist der Grund für die letzte Stufe seiner 28-jährigen Karriereleiter im BND. Am selben Tag, an dem der Spiegel diesen Skandal enthüllt, wird der damalige Abteilungsleiter Dieter Urmann strafversetzt. Fechner wird sein Nachfolger und bleibt es bis zur Rente.

Klassentreffen der Spione

Während sich diese Ereignisse in Deutschland abspielen, ist der BND-Agent mit dem Tarnkürzel „H.F.“ auf Dienstreise in den USA. Dort heißt der Präsident noch George W. Bush – und dessen handverlesene CIA-Unterstützung bei Auslandsreisen manchmal Edward Snowden. H.F. ist zu Gast im Hauptquartier der NSA, auf der jährlichen SIGDEV-Konferenz, wo sich über tausend Agenten über neueste Entwicklungen der Überwachungstechnik austauschen. Während der BND in Deutschland unter Druck steht, darf er hier glänzen.

Auf Einladung der NSA präsentiert H.F. einen Angriff auf das Tor-Netzwerk, den die BND-Hacker kurz vorher entwickelt haben. Der „Zwiebel-Router“ ist ein Netzwerk zur Anonymisierung von Internet-Kommunikation und hat sich zum König der Internet-Anonymisierungsdienste entwickelt, Millionen von Menschen auf der ganzen Welt nutzen Tor zum Schutz vor Überwachung und Zensur.

Tor wurde ursprünglich vom US-Militär ins Leben gerufen, um Geheimdienst-Aktivitäten im Internet zu verschleiern, und erhält bis heute einen Großteil seiner Finanzierung von der US-Regierung, um „Repression, Überwachung und Kontrolle im Internet“ in autoritären Staaten zu umgehen. Doch nicht nur Diktatoren ist Tor ein Dorn im Auge, auch westliche Behörden wollen Tor-Nutzer deanonymisieren. Und dabei will der BND helfen.

Angriff auf das Tor-Netzwerk

Ein paar Wochen vor der Konferenz haben die BND-Hacker vom Referat 26E „die Idee zu einem Verfahren entwickelt, wie relativ einfach das Tor-Netzwerk aufgeklärt werden könnte“, heißt es in internen BND-Unterlagen. Tor ist zu dieser Zeit schon relativ bekannt und hat 200.000 aktive Nutzer auf der ganzen Welt. Wenn Projekt-Chef Roger Dingledine die Funktionsweise auf dem CCC-Congress oder in einer Polizeidienststelle in Stuttgart erklärt, hören auch die Hacker vom BND aufmerksam zu.

Im März 2008 weiht der Geheimdienst die Partner aus den USA und Großbritannien in seinen Plan ein. Beim Besuch einer ausländischen Delegation in München präsentiert die Abteilung TA „das Anonymisierungsnetzwerk Tor und eine mögliche Auflösung der Anonymisierungsfunktion“, schreibt der BND in einem internen Besprechungsbericht. Um den Plan umzusetzen, wünscht sich der BND „eine internationale Zusammenarbeit mit mehreren ausländischen Nachrichtendiensten“.

NSA und GCHQ bekunden „hohes Interesse“ und sagen Unterstützung zu. Die drei Geheimdienste beschließen weitere Treffen und die Zusammenstellung einer Projektgruppe, der BND plant den Aufbau eines eigenen Tor-Exit-Servers sowie eine „Probeerfassung und Auswertung mit der NSA“.

Den Amis weit voraus

Im April präsentiert der BND-Agent H.F. die Arbeit der Pullacher Hacker bei der Anti-Terror-Koalition des europäischen Geheimdienst-Verbunds SIGINT Seniors Europe. Daraufhin lädt ihn die NSA zur SIGDEV-Konferenz in ihrem Hauptquartier ein. Wieder ist sein Vortrag ein Erfolg: Die anderen Geheimdienste sind „nachhaltig beeindruckt von unseren Leistungen zu Tor-Servern“, schreibt der BND später, man ist „den Amis da weit voraus“.

Die NSA sagt „eine fachliche Prüfung durch deren Experten“ zu, mit dem Ziel, das Projekt umzusetzen. Schon eine Woche später wird H.F. erneut von der NSA eingeladen, diesmal zusammen mit „M.S.“ aus der Hacker-Einheit, und diesmal nach Bayern, in das Verbindungsbüro der NSA in der BND-Außenstelle Bad Aibling. H.F. und M.S. haben dort eine Videokonferenz mit Experten der NSA, um weitere Fragen und Ideen zu klären. Das Protokoll dieser Konferenz veröffentlichen wir an dieser Stelle.

BND und NSA sind sich einig, dass „das Tor-Netzwerk das bisher im Internet am besten etablierte System zur Anonymisierung ist“ und „die anderen Systeme nur eine Nischenrolle spielen“. Die Geheimdienste erwarten, dass „das Tor-Netzwerk weiter stark wächst“, was „noch einige Jahre ein Problem darstellen wird“. Die Spione gehen davon aus, dass sich „Bemühungen für einen Ansatz lohnen“. Gemeint sind Angriffe, um die Anonymisierung von Tor rückgängig zu machen.

Bemühungen für einen Ansatz

Wie genau die Geheimdienste Tor knacken wollen, bleibt vage. Um Forschung und Feedback zu fördern, ist Tor transparent und offen. Nicht nur DesignSpezifikation und Quelltext sind öffentlich, auch eine eigene Datenbank mit wissenschaftlicher Forschung zum Thema Anonymität im Internet. Diese Offenheit hilft nicht nur Forschern, sondern Tor profitiert selbst davon: Immer wieder wird das System analysiert – und falls eine Schwachstelle auftaucht, wird sie geschlossen.

Die BND-Hacker sprechen gegenüber der NSA zwar von „einer Penetrationsmöglichkeit des Tor-Netzwerks“, worunter gemeinhin das Eindringen in fremde IT-Systeme verstanden wird. Im vorliegenden Fall spricht viel dafür, dass die Geheimdienste vielmehr eine Design-Entscheidung ausnutzen wollen, die Tor getroffen hat.

Das Prinzip von „Zwiebel-Routing“ ist es, Internet-Verkehr über drei Zwischen-Server zu leiten, so dass kein Punkt im Netzwerk gleichzeitig Sender und Empfänger kennt. Damit verhindert Tor viele Überwachungs- und Zensur-Maßnahmen, mehr als ein „Virtual Private Network“ (VPN), das nur einem Zwischenserver hat. Aber eben nicht alle.

Weltweiter, passiver Angreifer

Wie alle in der Praxis eingesetzten Anonymisierungs-Systeme dieser Art kann auch Tor nicht gegen „einen weltweiten passiven Angreifer“ schützen. Das steht so explizit im Design-Dokument. Auch die Dokumentation warnt: „Wenn ein Angreifer den Internet-Verkehr beobachten kann, der aus ihrem Rechner kommt und den Verkehr, der an dem von ihnen gewählten Ziel ankommt, kann er mit statistischen Analysen herausfinden, dass beide zusammen gehören.“ Die Internet-Überwachung von NSA und GCHQ tut genau das.

Eine ganze Reihe an Forschern hat diesen Angriff praktisch demonstriert, durch simples Zählen der übertragenen Pakete, über die Analyse von Zeitfenstern bis zur De-Anonymisierung durch einen Bruchteil des Verkehrs. All diese Forschung ist öffentlich einsehbar. Die Geheimdienste beobachten diese Forschung, nutzen sie für eigene Zwecke und nutzen theoretische Schwachstellen in ihrer praktischen Überwachung aus.

Die Hacker vom BND stützen sich bei ihrem Angriff auf „eine Studie einer amerikanischen Universität“, die sie auch an die NSA weitergeben. Bei der Videokonferenz in Bad Aibling beantwortet der BND Nachfragen und stellt einen Zeitplan mit weiteren Schritten vor. Die Deutschen wollen innerhalb von „sechs bis acht Wochen“ ein eigenes Tor-Netzwerk im Labor aufbauen, um das System besser zu verstehen und die Studie zu überprüfen.

Test-Netzwerk und Prototyp

Die NSA ist begeistert vom Vortrag des BND und will weiter eng zusammenarbeiten, vor allem will sie die Testergebnisse. Die Amerikaner sind „sichtlich erstaunt“ über die Aktivität der Deutschen. Zwar sieht sich der BND „etwas weiter als die NSA“, aber auch Pullach will, dass Fort Meade mitmacht: Das Vorhaben „hätte in einem Partnerverbund erheblich größere Erfolgsaussichten“.

Die NSA sagt zu, die Universität zu kontaktieren, um mehr über die Studie zu erfahren. Der BND macht sich an die Arbeit, setzt das Test-Netzwerk auf und entwickelt einen Prototyp des Angriffs, den „Proof of Concept“. Schon einen Monat nach der Videokonferenz sollen erste Ergebnisse vorliegen. Im Oktober will Harald Fechner, Leiter der Abteilung Technische Aufklärung, in die USA fliegen und das Thema mit NSA-Direktor Keith Alexander besprechen.

Doch dann bekommt das Projekt einen Dämpfer. Die Arbeitsgruppe IT-Operationen wird umorganisiert und die am Tor-Projekt beteiligten Hacker werden „innerhalb eines Referates zerstreut“, auf zwei verschiedene Sachgebiete. Im Dezember 2008 gibt es dennoch eine weitere Besprechung zu Tor im NSA-Hauptquartier, „die mit Abstand intensivste, was Anzahl der Teilnehmer und Kompetenz anging. Der Raum war voll.“

Den Amis was versprochen

Richtige Bewegung entsteht erst wieder zum Wechsel der US-Präsidentschaft von George W. Bush zu Barack Obama. Am Tag der Amtsübergabe bereitet die „Führungsunterstützung“ des BND einen neuen Besuch von Abteilungsleiter Fechner bei der NSA in den USA vor. In internen E-Mails bekommen die Hacker den Auftrag, das Projekt zu reaktivieren. Der BND hat „den Amis ja was versprochen“.

Damit übernimmt M.S. die Leitung des Projekts. Er beschwert sich über die „knappe Ressource brillantes Personal“ und mangelndes Interesse innerhalb des BND. Nach einer internen Vorstellung des Systems „kam nichts mehr“. Ab jetzt ist „die Weiterentwicklung primär auf den Bedarf des Partners ausgerichtet“. Der Proof-of-Concept ist schonmal „ein guter Stand, um mit den Experten der Amis zu reden“.

Der BND-Spitze kommt das gelegen. Man erhofft sich zwar, dass auch die BND-eigene Auswertung wieder „angestoßen“ werden kann, an Tor zu arbeiten. Aber das eigentliche Ziel ist größer. Der BND will etwas von der NSA: Eine Technologie aus dem „Bereich Kryptoanalyse“, zur Entzifferung verschlüsselter Inhalte. Pullach weiß, dass Fort Meade das Objekt der Begierde „erfahrungsgemäß nicht so leicht herausrücken“ wird. Deshalb sammeln die Deutschen Gegenleistungen, der Angriff auf Tor ist „ein weiterer Baustein“ dafür.

Gemüse-Zerkleinerer gegen Zwiebeln

Die Führungsunterstützung erteilt M.S. den Auftrag, innerhalb eines Monats ein Konzept zu verfassen. Und er liefert. Am 20. Februar 2009 steht ein 16-seitiges „Konzept für die Rückverfolgung von Internetverkehren, die mit dem Tor-System anonymisiert wurden“. Das Deckblatt ist wenig bescheiden: Über der Zwiebel im Tor-Logo prangt ein Gemüse-Zerkleinerer.

Zur Rechtfertigung der Tor-Überwachung zitiert M.S. die Berliner Sicherheitsgespräche, die in dem Jahr unter dem Motto „WWW – der virtuelle Tatort“ stattfanden. Beim Kapitel „Funktionsweise des Tor-Netzes“ macht sich der Autor wenig Arbeit, er kopiert den Text aus der Wikipedia und die Bilder von der Tor-Webseite.

Wie genau der BND Tor „zerhäckseln“ will, ist in der uns vorliegenden Version leider weitgehend geschwärzt. Doch wie zuvor beruft sich der Geheimdienst auf öffentliche Forschung. Zur Umsetzung dürfte der BND eigene Server im Tor-Netzwerk betreiben. M.S. verweist auf passiv schnüffelnde Server, die mutmaßlich von der NSA betrieben werden und betont den „Schutz der eigenen Anonymität“ der Geheimdienste.

In hohem Maße an Zugängen interessiert

Drei Wochen nach dem Konzept-Papier meldet der britische Geheimdienst wieder Bedarf an. Der GCHQ-Resident in Berlin und drei weitere ranghohe Spione der Königin sind am 11. März 2009 zu Besuch in Pullach. In der BND-Zentrale werden die Briten von Abteilungsleiter Harald Fechner empfangen, der sieben weitere leitende Mitarbeiter der Technischen Aufklärung mitbringt. Thema ist die Weiterentwicklung der SIGINT-Zusammenarbeit, besonders „bei den Anonymisierungsdiensten“.

Die Briten wollen mitmachen: Das GCHQ „ist in hohem Maße an den Zugängen der Abteilung TA zum Tor-Netzwerk interessiert“, heißt es im internen Besprechungsbericht. Beide Seiten vereinbaren weitere Fachgespräche zwischen Technikern und einen „gemeinsamen Workshop zu möglichem technisch/betrieblichem Vorgehen“.

Fünf Tage nach dem Besuch von der Insel fliegt Abteilungsleiter Fechner über den Atlantik, im Gepäck das Konzept-Papier von M.S.. Die Amerikaner nehmen das Gastgeschenk gerne an, NSA und GCHQ übernehmen das Projekt. Ob der BND die erhoffte Gegenleistung erhält, konnten wir leider nicht in Erfahrung bringen. Auf Anfrage erhalten wir die Standard-Antwort: „Zu operativen Aspekten seiner Arbeit äußert sich der BND grundsätzlich nur gegenüber der Bundesregierung und zuständigen Stellen des Bundestages.“

Sehr hohe Überwachungsdichte

Anderthalb Jahre später warnt der BND deutsche Bundesbehörden davor, Tor zu verwenden. Der „Anonymisierungsdienst Tor garantiert keine Anonymität im Internet“, betitelt die Hacker-Abteilung „IT-Operationen“ eine Meldung. Das sechs-seitige Papier geht am 2. September 2010 an Kanzleramt, Ministerien, Geheimdienste, Bundeswehr und Polizeibehörden.

Laut Kurzfassung ist Tor „ungeeignet“ für drei Szenarien: „für die Verschleierung von Aktivitäten im Internet“, „zur Umgehung von Zensurmaßnahmen“ und für „Computernetzwerkoperationen für Nachrichtendienste“ – also geheimdienstliches Hacking. Der BND geht „von einer sehr hohen Überwachungsdichte innerhalb des Netzes“ aus, unter anderem durch „die Möglichkeit, selbst sogenannte Exit-Knoten zur Überwachung einzurichten“.

In einer technischen Beschreibung erklärt der BND die Funktionsweise von Tor. Die Bilder sind erneut geliehen: von einer privaten deutschen Seite und der Electronic Frontier Foundation, in veralteter Form. Der BND macht auch inhaltliche Fehler: Dass „die Information über die vorhanden Tor-Knoten unverschlüsselt von einem Server geladen“ werde, war zu diesem Zeitpunkt schon über zwei Jahre lang falsch. Nachdem der Iran diese Verbindungen erkannt und blockiert hat, werden sie ab 2007 verschlüsselt.

Von Legalität nicht überzeugt

In der Meldung stellt der Geheimdienst unter Berufung auf „mehrere nachrichtendienstliche Hinweise“ eine gewagte These auf: Laut BND wird Tor „überwiegend zur Verschleierung von Aktivitäten benutzt, von deren Legalität die Handelnden nicht überzeugt sind. Die Anzahl der Tor-Nutzer mit dem Fokus auf Wahrung der Anonymität aus reinen Datenschutzüberlegungen ist im Verhältnis dazu sehr gering.“ Diese Behauptung belegt der BND nicht mit Fakten.

Wir haben diverse Personen aus dem Tor-Projekt gefragt, niemand kann die These des BND nachvollziehen. „Das klingt sehr nach Blödsinn“, sagt der IT-Sicherheits-Berater Jens Kubieziel, der Server für das Tor-Projekt administriert und große Tor-Exit-Server betreibt. Auch der Chaos Computer Club betreibt einige der großen Server im Tor-Netzwerk. „Verglichen mit der Menge des Traffics und der Millionen von Verbindungen, die jeden Tag durch Tor anonymisiert werden, ist die Anzahl der Anfragen wegen rechtswidriger Aktivitäten verschwindend gering“, sagt Rechtsanwalt Julius Mittenzwei, einer der Projekt-Verantwortlichen und ehemaliges Mitglied im Vorstand des Tor-Projekts.

Der BND schreibt weiter: Geheimdienste und andere Behörden weltweit „haben Ansätze, die Anonymisierung auszuhebeln. Einer davon ist das Aufsetzen eigener Tor-Knoten und deren intensive Überwachung zum Zwecke der Ermittlung und Beweiserhebung.“ Daraus machen die Geheimdienste untereinander kein Geheimnis: „Einige Dienste haben über das Installieren eigener Tor-Knoten und die Verwertung der Protokolldaten für verschiedene Projekte und Ermittlungsverfahren bereits berichtet.“

Verschleierung nicht gegeben

Einen deutlichen Hinweis, dass Geheimdienste Tor-Server betreiben, sieht der BND in den Standorten diverser Server, vor allem „im Umkreis von Washington, D.C.“. Der BND geht davon aus, „dass diverse Behörden diese Knoten zur Verfügung gestellt haben“. Aus dem Dokument geht nicht direkt hervor, ob der Geheimdienst das nur vermutet, im Internet gelesen hat, mitgeteilt bekam – oder ob der BND die NSA überhaupt erst auf die Idee gebracht hat.

Der BND ist sich jedoch so sicher, dass er die wichtigsten Bundesbehörden davor warnt, Tor zu benutzen. Das Fazit seiner Bewertung: „Die Nutzer von Anonymisierungssoftware gehen von einer Verschleierung ihrer Identität beim Surfen im Internet aus, die bei bekannten und weit verbreiteten Anonymisierungsdiensten nicht gegeben ist.“

Doch nicht nur Tor hält der BND für unsicher, auch von gehackten Rechnern als Proxy-Server raten die Hacker ab: „Die Verwendung eines kompromittierten Systems durch fähige Nachrichtendienste zum Zwecke einer als letztlich unwirksam bekannten Tarnung erscheint nur für Ablenkungsmanöver plausibel.“ Die BND-Abteilung „IT-Operationen“ muss es ja wissen – und warnt seine Hacker-Kollegen von BKA, Verfassungsschutz und Bundeswehr.

Tempora und XKeyscore

Angesichts der Aktivitäten von NSA und GCHQ ist die Sorge des BND berechtigt. Zwei Jahre nach dem Geschenk der Deutschen setzen diese Geheimdienste die Arbeit fort, Tor zu brechen. Im GCHQ-internen Wiki, das der Spiegel aus den Snowden-Dokumenten veröffentlicht hat, ist die Arbeit des britischen Teams dokumentiert. Auch ihr Ziel ist es, anhand von Internet-Verkehr eines Tor-Exit-Servers die Identität des Absenders herauszufinden.

Laut dem Wiki beginnt die Forschung im Dezember 2010. Den Briten ist es zu aufwändig, den Weg durch das Tor-Netzwerk zu verfolgen. Also korrelieren sie den Internet-Verkehr vom Sender zum Netzwerk und vom Netzwerk zum Empfänger. Weil das GCHQ massenhaft Internet-Verkehr mitschneidet und eigene Tor-Server betreibt, fällt das nicht weiter schwer. Schon im Juni 2011 ist eine 18-seitige Studie und Quellcode in der Statistik-orientierten Programmiersprache R fertig, dazu gibt es eine Präsentation mit Slides.

Auch die NSA ist erfolgreich. Ebenfalls 2011 sind „mehrere Fingerabdrücke und ein Plugin“ in ihrer mächtigen Spionagesoftware XKeyscore implementiert, um Tor-Nutzer zu erkennen und zu deanonymisieren. NDR und WDR haben einige dieser XKeyscore-Regeln veröffentlicht. Demnach überwacht die NSA alle Internet-Nutzer, welche die Tor-Webseite besuchen, die Tor-Software nutzen oder einfach nach Tor oder dem Tor-Betriebssystem Tails suchen.

Egoistische Giraffe

Trotz aller Angriffe ehrt selbst die NSA Tor noch immer als König der Internet-Anonymisierungsdienste. Auch wenn die Geheimdienste, die große Teile des Internets überwachen, einige Tor-Nutzer deanonymisieren können, ist es unwahrscheinlich, dass sie jederzeit alle Tor-Nutzer deanonymisieren können. Die NSA schreibt selbst, sie hat noch keine Wunderwaffe.

Anonymisierung ist wie Verschlüsselung: einfacher zu umgehen als zu knacken. Wer in einen Rechner einbricht, kann dessen Kommunikation entschlüsseln und Nutzer identifizieren. NSA und GCHQ machen das spätestens seit 2013: Unter dem Codenamen Egoistische Giraffe hacken sie den auf Firefox basierenden Tor Browser, infizieren das Betriebssystem und lösen so ihr selbst ernanntes „Tor-Problem“. Auch das FBI hat solche Angriffe schon ausgeführt und zugegeben.

Doch manchmal reicht es bereits, Fehler der Überwachungs-Ziele auszunutzen. Der LulzSec-Hacker Hector Monsegur wird enttarnt, weil er ein einziges Mal seine richtige IP-Adresse preisgibt. Der Stratfor-Hacker Jeremy Hammond wird enttarnt, weil das FBI korreliert, wann sein WLAN genutzt wird. Der Silk-Road-Gründer Ross Ulbricht wird enttarnt, weil er sein Pseudonym bekannt gibt. Eine aktuelle Studie beschreibt, wie man seine Anonymität trotz Tor-Nutzung verlieren kann.

Keine rein technischen Maßnahmen

Das Bundesamt für Verfassungsschutz hat weniger Erfolg. Obwohl der Inlandsgeheimdienst das Memo vom BND bekommt, hat er noch zwei Jahre später Probleme, Tor-Nutzer zu identifizieren. Auf einer Dienstreise in Washington im Juni 2012 fragt eine Delegation die NSA, ob diese Tor „identifizieren“ bzw. „entschlüsseln“ kann. Die Antwort stellt sie nicht zufrieden. In der internen Wertung des Besuchs schreiben die Deutschen, der Besuch war zwar „strategisch wichtig“, diente „jedoch eher der Beziehungspflege“.

Die großen Auslandsgeheimdienste bauen ihre Angriffe unterdessen weiter aus. Aber auch die Tor-Community arbeitet ständig daran, das Projekt zu verbessern und Angriffe abzuwehren – in engem Austausch mit der Wissenschaft. Chef-Entwickler Roger Dingledine ist skeptisch, ob die Geheimdienste in der Lage sind, „die gezeigten Angriffe in großem Maßstab durchzuführen“. Dennoch zeigen die Dokumente, „dass wir weiter daran arbeiten müssen, das Tor-Netzwerk auszubauen, um es Angreifern schwerer zu machen, diese Art Angriffe durchzuführen.“

Das kann aber nicht alles sein, so Dingledine: „Wir als Gesellschaft müssen etwas dagegen tun, dass Geheimdienste zu denken scheinen, keine Gesetze befolgen zu müssen. Gegen Angreifer, die Internet-Router und Nutzer-Geräte infiltrieren, die Entwickler und Forscher an Flughäfen zur Seite nehmen und verhören, die viele andere fragwürdige Maßnahmen einsetzen, gegen solche schrankenlosen Angreifer helfen keine rein technischen Maßnahmen. Sie müssen auch politisch in die Schranken gewiesen werden.“

Quelle: Geheime Dokumente: Der BND hat das Anonymisierungs-Netzwerk Tor angegriffen und warnt vor dessen Nutzung – netzpolitik.org

Veröffentlicht unter World-News | Kommentare deaktiviert für Geheime Dokumente: Der BND hat das Anonymisierungs-Netzwerk Tor angegriffen und warnt vor dessen Nutzung – netzpolitik.org