Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › BeA: Bundesrechtsanwaltskammer…

Vielleicht so gewollt

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Vielleicht so gewollt

    Autor: xploded 23.12.17 - 14:53

    Ist vielleicht kein Bug, sondern ein Feature. Per Gesetz eine Berufsgruppe dazu zwingen, so etwas zu nutzen und dann so einen Murks auf den Weg bringen - ein Schelm wer da etwas böses bei denkt!

  2. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 15:57

    ein arbeitskollege - jahrlanger softwareentwickler - hat mich mal gefragt, ob die header bei https auch verschlüsselt werden. allein schon die frage macht deutlich, wie wenig sich viele mit dem thema tls beschäftigen.

    interessant wäre zu wissen, wie das mit dem zertifikat des battlenet client ist. ich hab es mir nicht angesehen. aber schlussendlich wird es auch als root zertifikat installiert, oder? selbst wenn es auf jedem host neu erzeugt wird, könnte eine bösartige software den privaten teil wohl auslesen und möglicherweise schindluder damit treiben.

  3. Re: Vielleicht so gewollt

    Autor: hannob (golem.de) 23.12.17 - 16:48

    Was battle.net gemacht hat ist im Grunde ok. Sie erzeugen die CA und das Host-Cert auf jedem System neu, d.h. beide Keys sind jedesmal individuell. Wenn eine Schadsoftware das auslesen kann dann kann sie auch gleich das System übernehmen oder den Browser manipulieren, insofern ist da kein zusätzliches Risiko.

    Ich werd demnächst nochmal einen ausführlichen Erklärartikel zu dieser ganzen Sache mit den Localhost-HTTPS-Verbindungen machen, da es dabei sehr viel verwirrung gibt. Aber wohl erst im neuen Jahr.

  4. Re: Vielleicht so gewollt

    Autor: LiPo 23.12.17 - 16:54

    bjs schrieb:
    --------------------------------------------------------------------------------
    > ein arbeitskollege - jahrlanger softwareentwickler - hat mich mal gefragt,
    > ob die header bei https auch verschlüsselt werden. allein schon die frage
    > macht deutlich, wie wenig sich viele mit dem thema tls beschäftigen.

    was hat "jahrelanger softwareentwickler" damit zu tun, dass diese person sich "mit tls" nicht auskennt?
    glaubst du wirklich, dass jemand nur weil er "software entwickelt" deswegen ein IT universalwissen über alle themen und in maximaler tiefe hat?

    ich bin selbst softwareentwickler, java, schwerpunkte in webservices mit axis2 und rampart WSS, PDF bearbeitung mit itext, PDF und PS generierung mit apache FOP, beans programmierung für oracle forms.
    desweiteren bringe ich noch kenntnisse aus meinem voherigen betätigungsfeld als admin mit, solaris bis 10, linux, diverse serverinstallationen wie samba, tomcat, apache, cvs… , routing mit iptables, DNS… , hardwareeinkauf.

    ich weiss nicht mal wie man c++ programmiert, und windows kann ich auch nicht administrieren - jetzt bist du sicher *geschockt* ^^

    alleine einen apache https-proxy aufzusetzten bedeutet mindestens tagelanges rumschlagen mit diversen dokumentationen - das geht vom installieren eines server-zertifikats bis hin zur auswahl einer sicheren KEx verschlüsselung, bis hin zur apache filter config.
    hier mal zum schmökern:
    https://httpd.apache.org/docs/trunk/mod/mod_ssl.html
    und
    https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

    als kleines sahnehäubchen versuche mal heraus zu finden, was man machen muss wenn durch den http-proxy JSON daten geroutet werden sollen, die aber fälschlicherweise vom server als content-type text/html markiert sind.

    man kann nicht alles wissen. und vor allem crypto-krempel ist aufgrund der vielfältigen implementierungen, algorithmen und gleichzeitigen standards eine echte teergrube.

  5. Re: Vielleicht so gewollt

    Autor: pointX 23.12.17 - 16:54

    bjs schrieb:
    --------------------------------------------------------------------------------
    > gefragt, ob die header bei https auch verschlüsselt werden. allein schon die frage
    > macht deutlich, wie wenig sich viele mit dem thema tls beschäftigen.
    Wobei ich die Frage nicht gerade trivial finde.

    Hostname? -> Der steht clear im Zertifikat (ok, dann gibts noch Wildcards..) -> im Klartext vor Verschlüsselung übertragen.
    Sonstige Header von http (cookies, Get/Post usw.) -> verschlüsselt.
    Fällt wohl beides unter Daten, die ich als "header" zusammenfasse.

    Eine verschlüsselte Verbindung ist im Detail doch sehr komplex.
    Und selbst die Experten, die sich besser mit IT auskennen als 99,9% der Bevölkerung, sollten nicht "mal eben" versuchen etwas mit SSL zusammen zu basteln.

  6. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 17:31

    dass der key pro host erzeugt wird, steht im text von blizzard. es ist damit sicher besser, aber ich halte es nach wie vor für schlechtes design. schlussendlich ist es damit möglich, tls verbindungen aufzubrechen. die battlenet anwendung selbst kann es jedenfalls. eine lücke darin und eine im os, sodass dns umgebogen werden kann, und schon können alle tls verbindungen aufgebrochen werden. ich halte es für sehr schlechtes design, auch wenn die hürden größer sind und die ausnutzung komplizierter ist.

  7. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 17:38

    sorry, aber ja. wenn du schreibst "schwerpunkt webservices", dann musst du dich mit http und https auskennen. ebenso mit der technik, die dahinter steht. du musst wohl kein 802.1x kennen, aber die konzepte der protokolle, die du direkt verwendest, musst du kennen.

    also tagelang... wenn man einmal die passenden konfiguration hat, braucht es wohl nicht tagelang bei jeder installation. sowas sollte dann automatisch passieren. ebenso die tls konfiguration.

    man kann wohl nicht alles wissen, aber was du aufzählst ist keineswegs überragend viel sondern einfach nur normal.

  8. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 17:40

    > Hostname? -> Der steht clear im Zertifikat (ok, dann gibts noch
    er steht vor allem in der SNI information im klartext.

    > Eine verschlüsselte Verbindung ist im Detail doch sehr komplex.
    so komplex aber auch wieder nicht. :-) was bei https verschlüsselt ist und was nicht, darf man auch als softwareentwickler wissen.

    > Und selbst die Experten, die sich besser mit IT auskennen als 99,9% der
    > Bevölkerung, sollten nicht "mal eben" versuchen etwas mit SSL zusammen zu
    > basteln.
    eben deshalb sollten sie sich damit auskennen.

  9. Re: Vielleicht so gewollt

    Autor: xploded 23.12.17 - 18:15

    Das driftet nun aber in die falsche Richtung. Ich unterstelle nämlich nicht Unwissenheit, sondern pure Absicht. Bevor einer fragt: Nein, ich kann das natürlich nicht beweisen, deswegen unterstelle ich es ja nur.
    Ich kenne die Software nicht - aber mir stellen sich direkt ein paar weitere Fragen.
    Auf dem "Client" wird ein HTTP(s) Server installiert. Warum? Welcher Zweck steht dahinter? So wie ich es verstanden habe, geht es doch um "simple" Mailkommunikation?
    Vielleicht (!) findet sich ja ein sinnvoller Grund, stelle ich die nächste Frage: Wenn es einen HTTP(s) Server braucht, wie wird der von außen eigentlich erreichbar gemacht?
    Sollte nun jemand sagen: Der wird nur intern gebraucht, frage ich: Wieso dann der Aufriss um SSL, wenn nur lokal gebrutzelt wird.
    Oder wird vielleicht im Hintergrund ein VPN-CLient gestartet, der sich mit entsprechender Gegenstelle verbindet? Das wäre ja praktisch, dann braucht man sich ja nicht mehr drum kümmern, wie man den HTTP(s) Server von außen erreichbar macht - er ist es ja.
    Mit welchen Rechten läuft denn dieser HTTP(s) Server? Welcher Hersteller? Mit welchen Rechten auf dem System?
    Fragen über Fragen!

  10. Re: Vielleicht so gewollt

    Autor: cakruege 23.12.17 - 18:16

    hannob (golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Was battle.net gemacht hat ist im Grunde ok. Sie erzeugen die CA und das
    > Host-Cert auf jedem System neu, d.h. beide Keys sind jedesmal individuell.

    Noch mehr als das.
    Das CA-Zertifikat kann keinen Schaden anrichten.
    Die CA ist constrained auf DNS-Name=localbattle.net und den Zweck: Serverauthentifizierung (1.3.6.1.5.5.7.3.1)
    Blizzard hat das Problem absolut sauber gelöst.

    Die BeA-Nummer ist hingegen 100% Schwachsinnig. Wozu braucht man für eine localhost-Verbindung eine Verschlüsselung?

  11. Re: Vielleicht so gewollt

    Autor: plutoniumsulfat 23.12.17 - 18:22

    Vielleicht für lokale Mitm-Angriffe? :P

  12. Re: Vielleicht so gewollt

    Autor: LiPo 23.12.17 - 18:25

    bjs schrieb:
    --------------------------------------------------------------------------------
    > sorry, aber ja. wenn du schreibst "schwerpunkt webservices", dann musst du
    > dich mit http und https auskennen. ebenso mit der technik, die dahinter
    > steht. du musst wohl kein 802.1x kennen, aber die konzepte der protokolle,
    > die du direkt verwendest, musst du kennen.

    nein. das ist eigentlich aufgabe der administration. genauso wie routing, firewalls, DB indizierung, partitionierung und tuning.
    und… wie weit "muss" ich denn die protokolle kennen? http/s? tcp? das OSI schichtenmodell? also in- und auswendig?
    oder reicht es wenn ich weiß, das es sowas gibt, und das ich mich einarbeite wenn die notwendigkeit besteht?

    > also tagelang... wenn man einmal die passenden konfiguration hat, braucht
    > es wohl nicht tagelang bei jeder installation. sowas sollte dann
    > automatisch passieren. ebenso die tls konfiguration.

    klar. wenn man das konzept mal verstanden hat, muss man nur noch prüfen ob ein neuer apache bei einer neuen installation die gleiche config-api hat, und welche KEx denn nun verwendet werden sollen - stichwort: heartbleed.
    da aber eine solche installation immer ein paar jahre auseinender liegt, ist es jedesmal ein neues einarbeiten.
    wobei man natürlich die standard-config bei einer apache installation produktiv setzen kann, aber natürlich mit der gefahr das ein paar monate später ein BILD-artikel mit foto auf der ersten seite erscheint, überschrift: "10000de patientendaten im internet frei verfügbar - dümmster admin deutschlands".

    > man kann wohl nicht alles wissen, aber was du aufzählst ist keineswegs
    > überragend viel sondern einfach nur normal.

    kann sein, glaube ich aber nicht. vielleicht ist aber auch nur mein hirn zu klein, wobei ich eher davon ausgehe, dass du nicht wirklich weißt wovon du redest weil du nie wirklich in dem bereich *gerabeitet* und diese dinge *gemacht* hast.

    falls ich mich da irre - entschuldigung.

  13. Re: Vielleicht so gewollt

    Autor: xploded 23.12.17 - 18:25

    plutoniumsulfat schrieb:
    --------------------------------------------------------------------------------
    > Vielleicht für lokale Mitm-Angriffe? :P

    Richtig. Genau dafür. Steht ja auch so im Artikel drin.

  14. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 18:28

    du irrst dich sehr. entschuldigung angenommen.

  15. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 18:31

    bei den constraints wäre ich insofern vorsichtig, als dass es zeiten gab, zu denen einige tls implementierung diese constraints nicht beachtet haben. das problem ist, dass man das nicht bemerkt, ohne den code zu lesen bzw. es auszuprobieren.

  16. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 18:33

    https://www.golem.de/news/bridge-protonmail-startet-lokalen-imap-server-fuer-verschluesselung-1712-131565.html

    wäre wohl auch ein beispiel für eine sehr komplexe lösung.

  17. Re: Vielleicht so gewollt

    Autor: tingelchen 23.12.17 - 18:40

    LiPo schrieb:
    --------------------------------------------------------------------------------
    > bjs schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > sorry, aber ja. wenn du schreibst "schwerpunkt webservices", dann musst
    > du
    > > dich mit http und https auskennen. ebenso mit der technik, die dahinter
    > > steht. du musst wohl kein 802.1x kennen, aber die konzepte der
    > protokolle,
    > > die du direkt verwendest, musst du kennen.
    >
    > nein. das ist eigentlich aufgabe der administration. genauso wie routing,
    > firewalls, DB indizierung, partitionierung und tuning.
    > und… wie weit "muss" ich denn die protokolle kennen? http/s? tcp? das
    > OSI schichtenmodell? also in- und auswendig?
    > oder reicht es wenn ich weiß, das es sowas gibt, und das ich mich
    > einarbeite wenn die notwendigkeit besteht?
    >
    Ihr solltet die Protokolle schon beide kennen. Der Admin sollte sie kennen, damit die Fehlersuche einfacher wird und du solltest sie kennen, weil du sie verwendest. Der Admin muss die Protokolle lediglich lesen können (sofern überhaupt lesbar). Aber du schreibst Software basierend auf diesen Protokollen. D.h. du setzt Parameter, Einstellungen, etc. Je nach Protokoll.

    D.h. du hast es verwendet, aber eigentlich doch keine Ahnung was da eigentlich in deinem eigenen Code abgeht? ^^

    Es geht dabei nicht darum irgend einen Server auf zu setzen. Das macht schon der Administrator für dich. Dieser ist es auch der meistens auch die Zertifikate erstellt, bzw einrichtet und die Server Software entsprechend einrichtet. Damit du sie verwenden kannst. Aber was du über das jeweilige Protokoll verschickst, geht dem Admin erst einmal am Hintern vorbei. Der wird nur noch dann aktiv, wenn du mit deinem Tun sein Netzwerk störst ;)

  18. Re: Vielleicht so gewollt

    Autor: LiPo 23.12.17 - 18:43

    erzähl mal was genau du gemacht hast. ich hatte das gerne um meinen realitätssinn zu eichen - kann sein das ich da defizite habe.

  19. Re: Vielleicht so gewollt

    Autor: Anonymer Nutzer 23.12.17 - 18:54

    dem kann ich nur zustimmen.

  20. Re: Vielleicht so gewollt

    Autor: LiPo 23.12.17 - 19:00

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > LiPo schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > bjs schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > sorry, aber ja. wenn du schreibst "schwerpunkt webservices", dann
    > musst
    > > du
    > > > dich mit http und https auskennen. ebenso mit der technik, die
    > dahinter
    > > > steht. du musst wohl kein 802.1x kennen, aber die konzepte der
    > > protokolle,
    > > > die du direkt verwendest, musst du kennen.
    > >
    > > nein. das ist eigentlich aufgabe der administration. genauso wie
    > routing,
    > > firewalls, DB indizierung, partitionierung und tuning.
    > > und… wie weit "muss" ich denn die protokolle kennen? http/s? tcp?
    > das
    > > OSI schichtenmodell? also in- und auswendig?
    > > oder reicht es wenn ich weiß, das es sowas gibt, und das ich mich
    > > einarbeite wenn die notwendigkeit besteht?
    > >
    > Ihr solltet die Protokolle schon beide kennen. Der Admin sollte sie kennen,
    > damit die Fehlersuche einfacher wird und du solltest sie kennen, weil du
    > sie verwendest. Der Admin muss die Protokolle lediglich lesen können
    > (sofern überhaupt lesbar). Aber du schreibst Software basierend auf diesen
    > Protokollen. D.h. du setzt Parameter, Einstellungen, etc. Je nach
    > Protokoll.

    nicht so ganz. wenn ich z.b. java RMI verwende, halte ich mich an die API von oracle - was darunter läuft interessiert mich nicht.
    müsste ich mir alle darunter liegenden soft- und hardwareschichten als präsenzwissen aneignen, würde die software nie fertig werden.

    das idealisierte weltbild beißt sich da meiner meinung nach mit der realität.
    frag dich doch mal selbst was du alles verwendest - von programmier-APIs mal abgesehen - und von dem du nicht *bis ins detail* weißt wie es funktioniert.
    kannst du ein auto auseinender- und wieder zusammenbauen, zeitrahmen so ein/zwei wochen? nein? aber du benutzt doch eins, oder?
    wie sieht es mit deinem smartphone aus? kannst du aus dem stand eine JTAG analyse des hauptprozessors machen?

    in der regel nein. man benutzt frameworks (im weiteren sinn), weiß nicht wie sie intern aufgebaut sind, und verlässt sich darauf, dass sie und die restliche infrastruktur funktionieren.
    genauso wie du vertraust, das die GeoTrust CA die golem.de benutzt vertrauenswürdig, und tls_ecdhe_rsa_with_aes_128_gcm_sha256 sicher ist.

  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Schaeffler Technologies AG & Co. KG, Herzogenaurach
  2. Heidemark GmbH, Ahlhorn
  3. AVL List GmbH, Graz (Österreich)
  4. Badenoch + Clark, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 58,99€
  2. 169,90€ + Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


Adblock Plus: Adblock-Filterregeln können Code ausführen
Adblock Plus
Adblock-Filterregeln können Code ausführen

Unter bestimmten Voraussetzungen können Filterregeln für Adblocker mit einer neuen Funktion Javascript-Code in Webseiten einfügen. Adblock Plus will reagieren und die entsprechende Funktion wieder entfernen. Ublock Origin ist nicht betroffen.
Von Hanno Böck

  1. Urheberrecht Axel-Springer-Verlag klagt erneut gegen Adblocker
  2. Whitelisting erlaubt Kartellamt hält Adblocker-Nutzung für "nachvollziehbar"
  3. Firefox Klar Mozilla testet offenbar Adblocker

Elektromobilität: Was hat ein Kanu mit Autos zu tun?
Elektromobilität
Was hat ein Kanu mit Autos zu tun?

Veteranen der deutschen Autoindustrie wollen mit Canoo den Fahrzeugbau und den Vertrieb revolutionieren. Zunächst scheitern die großen Köpfe aber an den kleinen Hürden der Startupwelt.
Ein Bericht von Dirk Kunde

  1. EU Unfall-Fahrtenschreiber in Autos ab 2022 Pflicht
  2. Verkehrssenatorin Fahrverbot für Autos in Berlin gefordert
  3. Ventomobil Mit dem Windrad auf Rekordjagd

Swobbee: Der Wechselakku kommt wieder
Swobbee
Der Wechselakku kommt wieder

Mieten statt kaufen, wechseln statt laden: Das Berliner Startup Swobbee baut eine Infrastruktur mit Lade- und Tauschstationen für Akkus auf. Ein ähnliches Geschäftsmodell ist schon einmal gescheitert. Dieses kann jedoch aufgehen.
Eine Analyse von Werner Pluta

  1. Elektromobilität Seoul will Zweirad-Kraftfahrzeuge und Minibusse austauschen
  2. Rechtsanspruch auf Wallboxen Wohnungswirtschaft warnt vor "Schnellschuss" bei WEG-Reform
  3. Innolith Energy Battery Schweizer Unternehmen entwickelt sehr leistungsfähigen Akku

  1. Quartalsbericht: Amazons Umsatz steigt nicht mehr so stark
    Quartalsbericht
    Amazons Umsatz steigt nicht mehr so stark

    Amazon macht im ersten Quartal 3,6 Milliarden US-Dollar Gewinn. Doch das Umsatzwachstum fällt von 43 auf 17 Prozent.

  2. Partner-Roadmap: Intel plant 10-nm-Desktop-Chips nicht vor 2022
    Partner-Roadmap
    Intel plant 10-nm-Desktop-Chips nicht vor 2022

    Roadmaps von Dell zufolge wird Intel in den kommenden Jahren primär das Mobile-Segment mit Prozessoren im 10-nm-Verfahren bedienen. Im Desktop-Bereich müssen Comet Lake und Rocket Lake mit zehn Kernen und 14 nm gegen AMDs Ryzen 3000/4000 mit 7(+) nm antreten.

  3. Mobilfunk: Nokia macht wegen 5G-Sicherheitsbedenken Verlust
    Mobilfunk
    Nokia macht wegen 5G-Sicherheitsbedenken Verlust

    Nokia kann von der US-Kampagne gegen Huawei nicht profitieren, sondern verbucht einen unerwarteten Verlust. Investitionen seien erforderlich, erklärte Konzernchef Rajeev Suri.


  1. 23:51

  2. 21:09

  3. 18:30

  4. 17:39

  5. 16:27

  6. 15:57

  7. 15:41

  8. 15:25