Ankündigung

Einklappen
Keine Ankündigung bisher.

Sicherheit Email-Versand - SSL Zertifikate und PGP

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Ein Apache muss doch nicht den gleichen Vhost via Port 443 (https) und Port 80 (http) bereitstellen.
    Wenn du keinerlei zugriff via normalen http willst, dann erstelle den Vhost NUR für https (Port 443) und lass den normalen weg (läuft dann auf den default-[error-]vhost des apachen auf) oder erstell einen extra für Port 80 der jenachdem was du genau willst, entweder NUR weiterleitet auf die https-variante oder ne Fehlermeldung bringt um die User zu belehren dass er doof ist und es doch bitte mit https versuchen soll (semi-freundliche variante mit link )
    [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
    | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

    Kommentar


    • #17
      ahh d.h. in der apache config lege ich mehrere vhost an die ich dann jeweils mti dem richtigen ordner verknüpfe.

      heißt ich müsste die hauptseite auch in einen extra ordner packen und dann schlicht etwas in der richtung:
      PHP-Code:
      <VirtualHost *:443>
      ServerName userdesk.domain.de
      DocumentRoot 
      /www/userdesk
      </VirtualHost>
      <
      VirtualHost *:80>
      ServerName domain.de
      ServerAlias domain
      .tld
      DocumentRoot 
      /www/hauptseite
      </VirtualHost
      oder stimmt so? für was steht den serveralias? kann ich hier weitere domains definieren die dann den entsprechenende docroot haben?
      also ServerAlias hauptseite.domain.de

      (läuft dann auf den default-[error-]vhost des apachen auf)
      wenn ich versuche auf userdesk.domain.de mit http zuzugreifen gibt er mir welche error seite aus?

      Kommentar


      • #18
        Wenn du es komplett trennen willst und getrennte applikationen hast kannst du es so auftrennen, andernfalls kannst du natürlich auch beide vhosts auf das gleiche Verzeichnis setzen und in der .htaccess versuchen alle Requests die auf /user/ gehen zu überprüfen ob es via https ist und wenn nicht auf die gleiche url mit https weiterleiten. Siehe
        mod_rewrite - Apache HTTP Server
        -> Redirect To SSL Using Apache’s .htaccess - Joseph Scott’s Blog (muss um überprüfung des pfads erweitert werden)


        ServerAlias sind weitere Domains die der Apache auf diesen Vhost schickt.

        Mit default-[error-]vhost ist kein dokument gemeint sondern ein spezieller vhost gemeint, dass man bei IP-basierten VHosts einen vhost _default_:Port machen kann der dann immer erscheint wenn eine nicht bekannte domain/subdomain aufgerufen wurde für die kein vhost existiert, wichtig, die _default_ -Vhosts (einer für port 80 http, einer für 443 https) dürfen keine Angaben zu ServerName und ServerAlias haben!
        -> core - Apache HTTP Server
        [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
        | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

        Kommentar


        • #19
          super danke wieder um einiges schlauer

          wenn nichts gegen die getrennten vhost spricht werd ich das so machen...

          ich müsste aber später auch in der hauptseite einen teil mit ssl verschlüsseln. da wäre dann die einzigste möglichkeit das per modrewrite zu lösen richtig?

          das mit dem default vhost schau ich mir an wenn der server rennt...

          Kommentar


          • #20
            Also meiner Meinung nach ist es, wenn du auch auf der Hauptseite SSL brauchst sinnvoller gleich beide vhosts auf das gleiche verzeichnis zu leiten, eine Applikation zu schreiben und in einer .htaccess dann zu regeln welche urls SSL verfordern und welche nicht.
            [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
            | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

            Kommentar


            • #21
              Hi,

              ich muss jetzt nochmal kurz das Thema PGP aufgreifen.. hab gerade GPGP installiert und damit etwas experimentiert Außerdem studiere ich gerade diverse Seiten über PGP..
              Jetzt ist mir hier auch einiges klarer.. aber ein Punkt wiederum nicht ^^

              Wenn ein Empfänger meiner verschlüsselten Email diese lesen muss benötigt er ja meinen Public Key. Diesen muss ich Ihm ja irgendwie mitteilen. z.b. im Header der Email als Link zum Key. Oder ich fahre vorbei und gebe Ihm den Key persönlich oder oder..
              Wirklich in Frage kommt ja nur Ihm in der Email einen Link zu setzten auf dem das Programm sich den Schlüssel holt...

              Aber: das bringt im endeffekt doch dann gar nichts mehr? wenn jemand die email abfängt kann den header auslesen, den link zum key und somit auch die email ??

              ein interessanter link zu pgp -->

              dort wird genau das problem beschrieben (Öffentliche Schlüssel vor Manipulation schützen)
              und auch eine lösung "bietet PGP die Möglichkeit, Schlüssel/Benutzer-Zuordnungen zu unterschreiben"

              da ich aber -VOR- der Registrierung eines Kunden in unserem Portal keine Kontakt zu diesem habe bzw. jemand kenne der den Kunden kennt gibt es keine Möglichkeit einen Key von einer vertrauenswürdigen Person zu unterschreiben....

              bleibt mir also nur noch den key per header mitzusenden.. aber: ist das überhaupt sinnvoll? oder zumindest ein wenig sinnvoll? oder würdet ihr sagen ssl und nicht noch zusätzlich PGP... ??

              Kommentar


              • #22
                Für was willst du SSL bei Email benutzen ? Und wo ? SSL und PGP sind 2 ganz verschiedene Dinge und bei Emails nicht wirklich vergleichbar.

                Auch wenn Teile von dem was ich hier schreib schon in der Thread aufgetaucht sind hier eine kleine Wiederholung:

                Wenn es dir um die Client-> Server, Server -> Server und Server -> Client Kommunikation geht (wobei Client jeweils das Mailprogramm ist und Server der Mailserver), dann hast du im normalfall NUR Zugriff auf das erste, also wie DEIN Client sich zu DEINEM Server verbindet, also ob er dabei SSL/TLS nutzt, oder nicht. Wie der Mailserver dann die Verbindung zum Mailserver des anderen aufbaut UND ob der gegenüber SSL beim abrufen verwendet, das ist im normalfall nichts was du beeinflussen kannst.
                Im Endeffekt wird SSL auch NUR für die Übertragung benutzt, die mit SSL verschlüsselten Pakete werden erstmal auf deinem Server entschlüsselt und unter Umständen abgespeichert (Anderer Server nicht erreichbar ... etc) , dann auf dem Mailserver des anderen übertragen (eventuell unverschlüsselt) und dann dort unverschlüsselt gespeichert und dann ruft erst der andere Client sie ab (eventuell auch unverschlüsselt).

                Wir haben also einen Haufen Punkte wo andere Leute unter Umständen die Mail lesen könnten:
                Die Administratoren beider Mail-Server und theorhetisch durch Man-in-the-middle Zwischen Server-Server und Server-Client.
                Alles Punkte wo SSL keinerlei Schutz bietet für den Inhalt der Email.
                Selbst wenn wir davon ausgehen dass SSL bei allen 3 Übertragungen genutzt wird, so bleiben immernoch 2 Orte übrig wo die Mail eine bestimmte Zeit lang unverschlüsselt liegt.

                So, jetzt weiter zu PGP, das ja ganz anders funktioniert, es hat nichts nur mit den Übertragungen zu tun, sondern es geht darum die komplette Nachricht von Anfang bis ende verschlüsselt zu haben und wenn gewünscht zu signieren, was ein relevanter Teil ist.

                Also nehmen wir mal ... Bob und Alice

                Bob will Alice eine Email senden.

                Was Bob jetzt braucht ist der Public-Key von Alice um die Email an Alice mit diesem zu verschlüsseln (und dann idealerweise über seinen eigenen Key zu signieren, aber das lassen wir für den Anfang weg. Wird die Email NICHT signiert, ist zwar die Übertragung der Email sicher, aber der Empfänger (hier Alice) weis nicht ob die Mail von dem kommt der derjenige vorgibt zu sein.)

                Um das nochmal klarer zu machen, JEDER der Alice eine Email schickt, verschlüsselt diese mit dem Public-Key von Alice! Das bringt nur eine Verschlüsselung mit sich die es anderen Leuten unmöglich machen sollte die Email zu lesen, kein Nachweis der Identität des anderen. Für den Nachweis der Identität des anderen ist die Signierung zuständig.

                So, weiter.
                Also, diese Mail kann man jetzt NICHT mit dem Public-Key von Alice ENTSCHLÜSSELN, sondern das kann Alice nur mit ihrem Private-Key.

                Jetzt haben wir Carol, die will die Email von Bob an Alice lesen. Was sie jetzt machen kann ist Bob einen falschen public-key unterjubeln zu dem sie den Private-Key hat um die Mail zu entschlüsseln, dann die Email abfangen, entschlüsseln, eventuell verändern und dann mit einem Weiteren Satz schlüsseln (Public + Private) verschlüsseln wieder weiterschicken an Alice.
                Hierbei kann Alice nicht auffallen dass die Email in Wirklichkeit von Carol kam, anstatt von Bob, weil eben bisher keine Signierung stattgefunden hat.

                Haben wir den gleichen Versuchsaufbau mit Signierung, muss Carol auch die Signierung fälschen über das eigene neue Paar aus Private und Public-key und das setzt vorraus dass Alice keinen Public-Key von Bob hat.
                Der Teil der also für die Sicherheit verantwortlich ist, ist es die Möglichkeit zu haben sicher zu sein dass der Key den man vom Gegenüber hat auch wirklich der Key dieser Person ist.

                Was sicheres PGP also vorraussetzt ist natürlich dass ich irgendwie sicher weis, dass der Key den ich von Alice hab, auch wirklich ihrer ist. Dazu macht man entweder über einen Fingerprint-Vergleich über ein "sichereres" Medium, via persönliches Treffen, Fingerprint auf der Visitenkarte, Telefonat oder ähnlichem und SIGNIERT anschließend den Key des anderen mit seinem eigenen oder man setzt auf vorhandene signaturen von Leuten denen man vertraut.
                Diese Signatur wird dann dem Key des anderen angehängt und in Zukunft mitverteilt (üblicherweise neben anhängen an die Mail, legt man seinen Key auch auf so genannten Key-Servern ab, das erleichtert das ganze.
                Man baut also ein Vertrauensnetzwerk auf das es einem erlaubt Keys über Signaturen anderer Leute die man selbst kennt und denen man vertraut (vor allem dass sie den Fingerprint-Vergleich ordentlich gemacht haben) auch als Sicher anzuerkennen.

                Um gleich mal ein Praxis-Beispiel zu bringen:

                Das ist mein Schlüssel auf einem Key-Server:
                http://pgp.mit.edu:11371/pks/lookup?...978D51B23A4C0B
                Das der den ich auf meiner Webseite liegen habe:
                http://www.robo47.net/media/daten/0xB23A4C0B.asc

                Das ist das was in dem Schlüssel drinsteht menschenlesbar:

                http://pgp.mit.edu:11371/pks/lookup?...978D51B23A4C0B

                Es gibt also 2 Personen, Julius und Johannes die meinen Schlüssel (bzw. Teile davon) signiert haben. Wenn du also jetzt einen der beiden kennen würdest und ihnen ausreichend vertrauen würdest, hättest du damit dein Gewissen befriedigt, dass dieser Key wohl auch wirklich meiner ist.

                Diese Signaturen sind eine Alternative zum eigenen Fingerprint-Abgleich, wenn dieser nicht zur Verfügung steht.

                So ich hoffe mal ich hab nichts falsches erklärt, ansonsten bitte jemand korrigieren

                Also wie du siehst haben SSL und PGP unterschiedliche Funktionen und bieten unterschiedlichen Schutz. PGP im Gegensatz zu SSL bietet Sicherheit von deinem Rechner bis zum Rechner des anderen, während SSL nur teile abdeckt.
                Ob du PGP einsetzt, hängt primär erstmal davon ab an wen du dich wendest und ob du diesen Leuten überhaupt zutraust damit umgehen zu können und sich über den Rest dahinter klar zu sein.

                Du musst dir bei PGP also überlegen ob du es brauchst/willst, ob Signaturen reichen und wie du den Leuten mit denen du so kommunizierst deinen Key zukommen lässt und dich vergewisserst dass deren Key den du hast auch stimmt.

                Es gibt z.b. auch die Möglichkeit wenn die Daten nicht sensibel sind, sondern nur der Nachweis des Ursprungs, die NUR zu signieren, das reicht dem gegenüber mit Kentnissen über deinen Key zu wissen die Mail ist wirklich von dir.
                [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
                | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

                Kommentar


                • #23
                  wow das war mal eine aufklärung wie im lehrbuch
                  nun der unterschied von ssl zu pgp war mir schon klar.. wie das mit pgp genau abläuft nich, aber das hast du mir ja schon wundervoll beschrieben

                  und genau ist auch mein problem. ich benötige den public key von alice. das ist in meinem fall nämlich so gut wie unmöglich...

                  zum sachverhalt: die pgp verschlüsselung wollte ich zum verschlüsseln von zugangsdaten einsetzen. d.h. ein kunde registriert sich auf unserer seite und ich sende ihm nach überprüfung der registrierung seine zugangsdaten zu. problem: der kunde ist neu, also habe ich auch noch kein public key von ihm.

                  was möglich wäre ist nach registrierung den kunden telefonisch um übergabe seines public key zu bitten. wobei wie du schon sagtest
                  an wen du dich wendest und ob du diesen Leuten überhaupt zutraust damit umgehen zu können und sich über den Rest dahinter klar zu sein.
                  also: hat der kunde überhaupt einen public key? im rechtlichen bereich um den es sich handelt gehe ich mal davon aus.. aber zu 100% kan ich das nicht sagen...

                  bei den daten handelt es sich wie gesagt um zugangsdaten. nicht weiter schlimm, jedoch sollte der inhalt der mit diesen abgerufen werden kann so sicher sein wie nur möglich um missbrauch bzw. fälschung zu vermeiden.

                  so. ich muss jetzt also erstmal klären ob pgp bei diesen kunden verbreitet ist.. dazu befrag ich am dienstag mal einen kollegen. als zweites stellt sich die frage wie ich den public key von dieser person bekomme. da bliebe eigentlich nur telefonisch.
                  und zu guter letzt stellt sich mir die frage. ist es den aufwand überhaupt wert?
                  oder wie steht die chance das die zugangsdaten abgefangen werden?

                  ich könnte natürlich auch alle 3 Monate den Kunden neue Zugangsdaten zukommen lassen..


                  und.. sofern du die zeit hast robo darfst du mir beim einrichten von den keys behilflich sein, natürlich entgeltlich


                  noch am rande: outlook kann mittlerweile pgp, oder? vor n paar jahren konnte es das ja noch nicht.. und die kunden werden zu 90% nur outlook einsetzten..

                  Kommentar


                  • #24
                    Das klingt aber aufwändig, was du da vor hast. Ist doch nur notwendig, wenn du mit Zugangsdaten unter anderem das Initialpasswort meinst? Das könntest du dann ja schon bei der Registrierung mit angeben lassen, oder liege ich da falsch?

                    Kommentar

                    Lädt...
                    X