Sebastian: welche Ports sind für SSL wichtig?

Hallo Forum,

Ich hätt' da gern ma' n Problem:

Ich hab ne T-Online "Flatrate" (also IP immer noch dynamisch)
Zu Hause habe ich einen DSL-Router stehen.
und viele Rechner, unter anderem n Web-Server (Linux)
Es ist mir nun gelungen SSL auf dem Server zu kriegen, klappt im LAN auch wunderbar.

Ohne SSL ist dieser auch wunderherrlich von außen zu erreichen* (lasse den Router 80er-Anfragen auf den Linux weiterleiten)

so weit so gut.

Nun wollte ich erreichen, dass mein Server von außen auch über SSL ansprechbar ist. Scheinbar scheint es hier aber nicht auszureichen den SSL-Port (443, so weit ich weiß) vom Router forwarden zu lassen. Denn, wie ich weiß, erfolgt ja beim allerersten Connect die Server-Zertifizierung. Und genau HIER ist mein Problem anscheinend angesiedelt: o.g. Zertifizierung scheint einen anderen Port nutzen zu wollen.
Welcher aber ist es?
Habe schon in ellenlangen Porterklärungs-Listen gesucht - bin aber leider nicht wirklich fündig geworden...

Kann mit jemand helfen?

_______________________
Mit freundlichen Grüßen
Sebastian

*dyndns.org lässt grüßen

  1. Moin,

    Nun wollte ich erreichen, dass mein Server von außen auch über SSL ansprechbar ist. Scheinbar scheint es hier aber nicht auszureichen den SSL-Port (443, so weit ich weiß) vom Router forwarden zu lassen. Denn, wie ich weiß, erfolgt ja beim allerersten Connect die Server-Zertifizierung. Und genau HIER ist mein Problem anscheinend angesiedelt: o.g. Zertifizierung scheint einen anderen Port nutzen zu wollen.

    Nein, 443/TCP reicht für HTTPS vollkommen aus. (Man kann es sogar auf jedem anderen Port machen, wenn man dem Browser nur sagt welchen man will. Aber ein Port reicht in jedem Fall aus.)

    Dein Problem liegt also wo anders. Vielleicht ein übereifriger Paketfilter (evt. sogar beim Provider)? Portforwarding doch nicht eingerichtet?

    --
    Henryk Plötz
    Grüße aus Berlin
    ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
    ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
    1. Moin,

      Nun wollte ich erreichen, dass mein Server von außen auch über SSL ansprechbar ist. Scheinbar scheint es hier aber nicht auszureichen den SSL-Port (443, so weit ich weiß) vom Router forwarden zu lassen. Denn, wie ich weiß, erfolgt ja beim allerersten Connect die Server-Zertifizierung. [snip]
      Nein, 443/TCP reicht für HTTPS vollkommen aus. (Man kann es sogar auf jedem anderen Port machen, wenn man dem Browser nur sagt welchen man will. Aber ein Port reicht in jedem Fall aus.)
      Dein Problem liegt also wo anders. Vielleicht ein übereifriger Paketfilter (evt. sogar beim Provider)? Portforwarding doch nicht eingerichtet?

      Hmm. Also wenn ich am Router einstelle, dass er Port 80 forwarden soll, tut er dass. Ich bin von außen erreichbar (getestet!). Sage ich ihm jetzt auch noch, dass er Port 443 weiterleiten soll, passiert im Browser gar nichts (wenn ich via https://... zugreifen will).

      Port-Filter sind nicht eingerichtet - weder auf Linux noch auf dem Router. In den monströs langen Portlisten habe ich allerhand "Port-Kandidaten" gefunden, die so klingen also würde über mindestens einen die Server-Zertifizierung laufen:

      • 585 tcp imap4-ssl IMAP4+SSL
      • 614 tcp sshell SSLshell
      • 695 tcp ieee-mms-ssl IEEE-MMS-SSL
      • 993 tcp imaps imap4 protocol over TLS SSL
      • 1203 tcp ssslic-mgr License Validation
      • 1204 tcp ssslog-mgr Log Request Listener
      • 2478 udp ssm-cssps SecurSight Authentication Server (SSL)
      • 2479 tcp ssm-els SecurSight Event Logging Server (SSL)
      • 2679 tcp syncserverssl Sync Server SSL
        Das lässt mich grübeln. Selbstverständlich verstehe ich davon nicht jedes Wort, weshalb das für mich wichtig klingt.

      So, bleibt also noch mein Provider, der evtl. sowas unterbinden könnte. Von außen kann man auf "mich" über http, ftp zugreifen, früher (als ich noch keinen Router hatte und einer meiner Rechner sozusagen "direkt" angeschlossen war) habe ich sogar manches mal Spiele serven können. Wieso sollte also ausgerechntet SSL _nicht_ gehen?

      Mist, alles Mist.

      Ich gebe nicht auf.
      Ich (wir?) finde(n) eine Lösung.

      Und wenn es das letzte ist, was ich _finde_.

      _______________________
      Mit freundlichen Grüßen
      Sebastian

      1. Hallo Sebastian,

        Hmm. Also wenn ich am Router einstelle, dass er Port 80 forwarden soll, tut er dass. Ich bin von außen erreichbar (getestet!). Sage ich ihm jetzt auch noch, dass er Port 443 weiterleiten soll, passiert im Browser gar nichts (wenn ich via https://... zugreifen will).

        Versuchst Du, von innen auf Dich selbst zuzugreifen oder von außen auf Dich?  Von innen klappt nämlich nur, wenn man bestimmte Dinge berücksichtigt. (das gleiche ist bei allen anderen Ports auch der Fall)

        Oder anders: Hast Du mal probiert, den SSL-Server auf Port 80 laufen zu lassen und dann mit https://...:80/ darauf zuzugreifen?

        Viele Grüße,
        Christian

        1. Hallo Christian

          Versuchst Du, von innen auf Dich selbst zuzugreifen oder von außen auf Dich?  Von innen klappt nämlich nur, wenn man bestimmte Dinge berücksichtigt. (das gleiche ist bei allen anderen Ports auch der Fall)

          Also von innen nach innen geht immer (Webserver direkt über IP ansprechen oder über den dyndns-Namen, führt beides zum Ziel.

          Oder anders: Hast Du mal probiert, den SSL-Server auf Port 80 laufen zu lassen und dann mit https://...:80/ darauf zuzugreifen?

          Das kann ich ja mal testen.

          Ich berichte dann später über meine Ergebnisse :-)

          _______________________
          Mit freundlichen Grüßen
          Sebastian

      2. Hallo,

        Hmm. Also wenn ich am Router einstelle, dass er Port 80 forwarden soll, tut er dass. Ich bin von außen erreichbar (getestet!). Sage ich ihm jetzt auch noch, dass er Port 443 weiterleiten soll, passiert im Browser gar nichts (wenn ich via https://... zugreifen will).

        Versuch doch mal von außen eine TCP/IP Verbindung zu Port 443 herzustellen. (z.B. über telnet oder so) Dann siehst du, ob du überhaupt eine Verbindung bekommst, oder ob das SYN Packet hier gleicht verworfen wird. (Also ich meine jetzt Timeout oder einfach eine Ablehung der Verbindungsaufforderung)

        Wenn es auf der TCP/IP Ebene klappt, dann ist das ein Problem mit der Konfiguration deines Webservers. Klappt es schon hier nicht, dann liegt es an deinem Router.

        Viele Grüße,

        Stefan

        --
        Lass dir das Tanzen NICHT verbieten
        http://petition-tanzverbot.de.vu
        1. Hallo

          Versuch doch mal von außen eine TCP/IP Verbindung zu Port 443 herzustellen. (z.B. über telnet oder so) Dann siehst du, ob du überhaupt eine Verbindung bekommst, oder ob das SYN Packet hier gleicht verworfen wird. (Also ich meine jetzt Timeout oder einfach eine Ablehung der Verbindungsaufforderung)
          Wenn es auf der TCP/IP Ebene klappt, dann ist das ein Problem mit der Konfiguration deines Webservers. Klappt es schon hier nicht, dann liegt es an deinem Router.

          Gute Idee,
          danke ich werd's testen.

          _______________________
          Mit freundlichen Grüßen
          Sebastian

          1. Moin,

            Versuch doch mal von außen eine TCP/IP Verbindung zu Port 443 herzustellen. (z.B. über telnet oder so) Dann siehst du, ob du überhaupt eine Verbindung bekommst, oder ob das SYN Packet hier gleicht verworfen wird. (Also ich meine jetzt Timeout oder einfach eine Ablehung der Verbindungsaufforderung)

            Gute Idee,
            danke ich werd's testen.

            Falls du keinen zweiten Rechner im Internet hast und uns deinen dyndns-Namen nicht mitteilen möchtest, kannst du zum Beispiel http://www.linux-sec.net/Audit/nmap.test.gwif.html benutzen. Schick' einfach das Formular ab.
            Bei der erscheinenden Seite siehst du einmal eine Zeile die dir sagt in welchem Zustand die meisten deiner Ports sind ("(The XXX ports scanned but not shown below are in state: closed)" zum Beispiel) und dann eine Auflistung der anderen Ports mit ihrem jeweiligen Zustand. Dabei bedeutet: open, dass da ein Dienst auf dem Port lauscht und die Verbindung annimmt, closed, dass die Verbindung standardkonform abgelehnt wird und filtered, dass die Verbindungsanfrage standardwidrig ignoriert und das einkommende Paket einfach weggeworfen wird. Letzteres tun viele kaputte Paketfilter. (Warum das schlecht ist steht in http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny.)

            Wenn du dann vielleicht noch drinnen einen Paketsniffer wie Ethereal laufen hast, kannst du vielleicht sogar sagen wo die Anfrage verloren geht. Wenn drinnen kein SYN-Paket mit Zielport 443 auftaucht, dann ist die Anfrage gar nicht bis in den Netz vorgedrungen.

            --
            Henryk Plötz
            Grüße aus Berlin
            ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
            ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
      3. Moin,

        Port-Filter sind nicht eingerichtet - weder auf Linux noch auf dem Router. In den monströs langen Portlisten habe ich allerhand "Port-Kandidaten" gefunden, die so klingen also würde über mindestens einen die Server-Zertifizierung laufen:
        [SNIP]

        Der größte Teil davon sind andere Dienste die über SSL gehen können. SSL heisst nämlich nur Secure Sockets _Layer_ ist also eine Schicht die man einfach unter andere Protokolle legen kann. Daher ist dein Topic auch arg unspezifisch, da man alles mögliche über SSL schickt. Aus deinem Text war aber ersichtlich, dass du HTTP over SSL kurz HTTPS meinst.

        Aber wie gesagt: Das Zertifikatsgekrame ist Bestandteil einer Verbindung und wird in ein und derselben TCP-Verbindung wie der darauffolgende Datentransfer abgehandelt. Andere Verbindungen wie bei manchen kranken Protokollen (etwa FTP, ächz) sind nicht nötig.

        --
        Henryk Plötz
        Grüße aus Berlin
        ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
        ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
  2. Hi,

    welche Ports sind für SSL wichtig?
    den SSL-Port (443, so weit ich weiß)

    SSL ist prinzipiell auf allen Ports möglich.

    Du meinst https, das üblicherweise auf Port 443 benutzt wird, das aber genausogut auf jedem anderen Port benutzt werden kann (bei mir z.B. auf 443 für den Apache und 8443 für den Tomcat).

    Zum eigentlichen Problem kann ich Dir leider nicht weiterhelfen.

    cu,
    Andreas

    --
    Der Optimist: Das Glas  ist halbvoll.  - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.
    http://mud-guard.de/? http://www.andreas-waechter.de/ http://www.helpers.de/
  3. Danke erstmal an alle,

    habe schon eifrig getestet - bisher immer ohne Erfolg.
    Wer Lust hat kann ja mal versuchen auf meinem Server zu connecten.

    http://brizly.dyndns.org bzw.
    https://brizly.dyndns.org

    Wundert euch nicht, dass da kaum was ist - die Seite ist für Zugriffe von Außen stark verschlankt (und, wie sollte es anders sein -> sie befindet sich im _Aufbau_) :]

    _______________________
    Mit freundlichen Grüßen
    Sebastian

    P.S.: Schlaft später schön. Für mich geht's sorgen früh weiter.
    *scharch*

    1. Moin!

      habe schon eifrig getestet - bisher immer ohne Erfolg.
      Wer Lust hat kann ja mal versuchen auf meinem Server zu connecten.

      So wie ich die Sache nach einer kurzen Suche bei Google sehe, ist HTTPS nicht so einfach Port-Forwarding-fähig, jedenfalls nicht auf Serverseite.

      Du bräuchtest wohl etwas mehr Software dafür. Beispielsweise einen HTTPS-Proxy auf deinem Router, der seinerseits dann Verbindung zum (jetzt noch HTTPS-)Server aufnimmt.

      Für diese Aussage übernehme ich aber keine Garantie. Ich bin nur irgendwie der Meinung, dass SSL ja die Verbindung zu einem konkreten Server für den Client sicherstellen soll. Wenn man diese Verbindung so einfach durch Port-Forwarding umleiten könnte, wäre der Sinn von SSL dahin.

      - Sven Rautenberg

      --
      ss:) zu:) ls:[ fo:} de:] va:) ch:] sh:) n4:# rl:| br:< js:| ie:( fl:( mo:|
      1. Moin,

        Für diese Aussage übernehme ich aber keine Garantie. Ich bin nur irgendwie der Meinung, dass SSL ja die Verbindung zu einem konkreten Server für den Client sicherstellen soll. Wenn man diese Verbindung so einfach durch Port-Forwarding umleiten könnte, wäre der Sinn von SSL dahin.

        Jein, die Zertifikate werden bei HTTPS an einen Servernamen gebunden. Wenn dahinter ein Portforwarding steckt macht das nichts und stört den SSL-Teil recht wenig. Schließlich gehen die Daten weiterhin verschlüsselt durch die Leitung.

        Sebastians Rechner scheint jetzt aber ganz offline zu sein.

        --
        Henryk Plötz
        Grüße aus Berlin
        ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
        ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
        1. [snip] die Zertifikate werden bei HTTPS an einen Servernamen gebunden. Wenn dahinter ein Portforwarding steckt macht das nichts und stört den SSL-Teil recht wenig. Schließlich gehen die Daten weiterhin verschlüsselt durch die Leitung.

          Das sehe ich auch so.

          Sebastians Rechner scheint jetzt aber ganz offline zu sein.

          Wie? Was? Hä? *hibbel* Nö. Eigentlich nicht. Bin immer online. Evtl mal 5 Minuten nicht, wenn ich grad ne neue IP verpasst bekommen hab und mein dyndns-Client 'hinterherhinkt'. Aber sonst: always online.
          Wie kommst du drauf? geht bei mir jetzt etwa nicht mal mehr Port 80 von draußen?
          *kreisch*

          1. Moin!

            Wie kommst du drauf? geht bei mir jetzt etwa nicht mal mehr Port 80 von draußen?
            *kreisch*

            Also ich kriege keine Verbindung zu deinem Server.

            - Sven Rautenberg

            --
            ss:) zu:) ls:[ fo:} de:] va:) ch:] sh:) n4:# rl:| br:< js:| ie:( fl:( mo:|
            1. Hallo Sven

              Also ich kriege keine Verbindung zu deinem Server.

              Ich habe das Problem gelöst (das meines Threads). Soll ich die ganze Geschichte erzählen? OK.
              Es war einmal (vor nicht allzu langer Zeit) ein Router [LinkSYS Etherfast Cable DSL Router "BEFSR11], dem konnte man supertolle Dinge beibringen. Desweiteren war (und ist, und bleibt!) einmal ein Linux (Redhat 8.0 [psyche]), ein passender PC dazu und ein tollpatschiger User (ich).
              Ich nun also Linux aufgesetzt, mit Apache und hastenichgeseh'n. Und warum? Weil ich beruflich wie freizeitlich PHP/MySQL/HTML/CSS/JS programmiere (ja, ich weiß, HTML programmiert man nicht). So. Server lief also (lokal). Was will man dann? Genau, dass der Server von außen erreichbar ist. Was tut man? Dyndns-Adresse besorgen und dem Router Bescheid sagen er solle Port 80 weiterleiten. Das ging auch. von außen wie von innen funzte meine dyndns-Adresse herrlich. Dann wollte ich natürlich etwas mehr Sicherheit. Also habe ich im Router festgelegt alle Ports überhalb der 1024 gesperrt (nach außen wie nach innen) UND nahezu im gleichen Zuge den Server um SSL für HTTP ergänzt (inklusive Port443-Weiterleitung am Router). Tja. Was dann? Testen. VPN zur Arbeit hin geht. POP3 geht, Surfen geht. Testen beendet (leichtsinnigerweise). Dann passierte das, was man im Thread so lesen kann.
              Und dann geschah es!
              Ich habe (mehr aus Verezweiflung) die Portsperren überhalb der 1024 entfernt - unn et jeeeeht!!
              <auf-180-sei>Wieso dat dann??? Was haben die 'oberen' Ports damit zu tun? Isch werd nochmal bleede mit den Teil hia! Kruzifix! Wie kann das sein! [blahblahblah...]
              </auf-180-sei>

              Naja, wie dem auch sei. Es geht. Das ist ja schonmal was. Jetzt fange ich dann mal an rauszufinden woran das liegt...

              Trootzdem danke für Eure Hilfe...

              _______________________
              Mit freundlichen Grüßen
              Sebastian

              1. Hi,
                Also ich kann auf den Server zugreifen!
                Und ich habe bei meiner Domain auch kein HTTPS-Proxy.
                Bei mir klappts einfach so: http://www.regensburger-seite.de https://www.regensburger-seite.de.
                Bitte das testzertifikat entschuldigen.
                MfG, Lars