[mw197]

Wie sieht es mit HTTPS für WinFuture aus?
Let's Encrypt bietet das ja beispielsweise kostenlos an

[RalphS]

$ openssl s_client -connect winfuture.de:443 -showcerts

CONNECTED(00000004)
---
Certificate chain
 0 s:/C=DE/OU=Domain Control Validated/CN=winfuture.de
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
-----BEGIN CERTIFICATE-----
[ ... ]
-----END CERTIFICATE-----
---
Server certificate
subject=/C=DE/OU=Domain Control Validated/CN=winfuture.de
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
---
SSL handshake has read 3551 bytes and written 634 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported

[ ... ]
$

Winfuture.de verwendet SSL. Auch schon seit halben Ewigkeiten. Man sieht es halt nur nicht immer. Gut, darüber kann man jetzt streiten; aber es ist hauptsächlich eine Performance-Geschichte; SSL-bedingter Overhead fällt an pro Verbindung und davon haben Foren notorisch jede Menge, sodaß ich diesen Schritt zumindest nachvollziehen kann.

Klar, wär schön, wenn da "immer" ein Schloß dastehen täte. Aber SSL wird verwendet, wo es zählt, nämlich beim Logon-Vorgang.

- Was man bei WF evtl tun könnte: die Login-Seite selber auch via HTTPs ausliefern und ggf zurückkommende Antwortseiten auch (=> insbes bei Fehlerstatus).

[dognose]

Winfuture nutzt SSL - genau richtig: Das Login erfolgt via SSL, der reguläre Inhalt wird unverschlüsselt übertragen.

Warum sollte man - öffentliche, für alle gleiche Inhalte "verschlüsselt" übertragen?
Das ist unnötiger Traffic-Overhead, der nicht sein muss.

Bei "geschlossenen" Webseiten wie einem Webmailer, der internen Firmen-Anwendung oder deinem Facebook Account ergibt das Sinn - Bei Winfture - außer beim Login - nicht.

Zitat

- Was man bei WF evtl tun könnte: die Login-Seite selber auch via HTTPs ausliefern und ggf zurückkommende Antwortseiten auch (=> insbes bei Fehlerstatus).

Wozu? Das Post-Target ist https - Anfrage-Formular sowie die Antwortseite sind "irrelevant".

---

Andere, große Anbieter verfahren "gleich" - Jedoch steht da auf dem Button dann nicht "Login", sondern "Login (weiter über den SuperDuper verschlüsselten Sicherheitsserver)" - sodass es auch jeder kapiert :-)

Dieser Beitrag wurde von dognose bearbeitet: 17. Oktober 2016 - 17:42

[RalphS]

Ganz einfach: Weil SSL hauptsächlich Vertrauenssache ist. Sieht man ja auch an diesem (und den anderen entsprechenden) Thread(s) hier; man "sieht" nicht, daß es eingesetzt wird und damit geht einem eben jenes Vertrauen außenrum.

Login- und eventuelle Antworten darauf via SSL ausliefern hieße, den Benutzern *anzuzeigen*, okay was hier über die Leitung geht, ist sicher, UND es geht auch *tatsächlich* an winfuture.de.

Dasselbe gilt so weitergehend für alle ausgelieferten Seiten, wobei natürlich wie gesagt fraglich ist, warum man ausgerechnet in einem *FORUM* (welches schon per definitionem öffentlich ist) für Privatsphäre sorgen sollte. Das haben wir aber schon beide gesagt.

Allerdings kann man halt durchaus dagegegen argumentieren und sagen, SSL stellt aber sicher, daß meine Postings auch tatsächlich an Winfuture.de bzw winfuture-forum.de gehen. Was dann natürlich in der Umsetzung auf die Performance gehen würde.

Zusätzlich stellt SSL sicher, daß auch die ausgelieferten Seiten selber von winfuture*.de stammen. Weniger SSL gleich "ich unterstelle, die Information stammt NICHT von winfuture.de, sondern ist kompromittiert";
hier sag ich persönlich "na und, kratzt mich nicht", aber das kann und darf ein jeder anders sehen. In jedem Fall wäre es definitiv ein Argument für "möglichst alles per SSL ausliefern".

WF hat da -so unterstell ich mal -- sicherlich schon drüber diskutiert intern und ist zum Entschluß gekommen, daß der Performanceoverhead zu groß werden würde, um besagtes Plus an Vertrauen zu rechtfertigen. Wo ich ua aus geschriebenen Gründen beipflichten würde.


--- Aber man könnte halt ausgewählte Seiten per https ausliefern, sozusagen als Kompromiß, nämlich da, wo es insbesondere zählt: die Login-Seite(n), die persönlichen Seiten (control panel uä.), die PM-Sektion hier im Forum, weitergehend evtl die Antwort'seiten im Forum (da dann sicherlich eher die /posting.php Seite für "Neuer Thread" und "Antworten" als /thread.php für die Threadanzeige selber, auch wenn man da auch antworten kann).

Das wäre dann eher ein Entgegenkommen an die Benutzer, eben in bezug auf jene Vertrauensbasis, über den technischen Aspekt hinaus (SSL ohne Vertrauen ist eh wertlos) und ohne einen 'echten' "Bedarf" (ie. daß es also absolut unumgänglich wäre).

-- Denn das aktuelle Modell hat die unleugbare Schwachstelle, daß der Benutzer™ nicht weiß (und nicht herausfinden kann), ob er wirklich grad bei winfuture.de oder winfuture-forum.de unterwegs ist oder nicht --- und ob die eben eingegebenen Logindaten eben bei winfuture.de/winfuture-forum.de *landen*; denn wenn das ne gefälschte Website wäre mit denselben Loginbuttons täte man ja auch nicht merken, wie und wohin DIESE Daten dann verschickt werden würden.

-- Die Sites, die Du da angibst re: hier gehts über Super Duper weiter? Gibt es. Klar. Aber die Mehrzahl hat zumindest eingesehen, daß SSL-was-man-nicht-sieht eher nichts bringt - *weil* man es nicht sieht. "Hier geht es verschlüsselt weiter" kann der Anbieter behaupten; "kein Schloß ergo kein SSL" können die Benutzer aber im selben Atemzug sagen und dann haben wir alles, aber keine Vertrauensbasis.

Dieser Beitrag wurde von RalphS bearbeitet: 18. Oktober 2016 - 04:00

[Wiesel]

Das Forum kann man im übrigen per https aufrufen... Mit einem selbst erstellten Zertifikat und den dazugehörigen Einschränkungen.

Und ganz ehrlich: selbst erstellte Zertifikate sind Grütze, da genauso sicher und nachvollziehbar wie ohne. Ein richtiges kostet mit allen sich daraus ergebenden Vorteilen. Hänge ich an mein Haus ein pappschild mit einem aufgemalten Schloss, ist die Tür nicht automatisch sicherer.

[RalphS]

Echt?

... Tatsache. Von 2009-10.

Selbstsigniert heißt ja nur, daß die Autorität von einem selber kommt. Wenn wir jetzt sagen, okay mesios, klingt gut nehm ich, dann packen wir das Zertifikat in unsere vertrauenswürdigen Stammzertifizierungsstellen und winfuture-forum.de wäre sozusagen in sich integer.

.... Mal probieren? Oder nicht? Decisions.

[Wiesel]

Ich kann aber die Verwendung nicht empfehlen. Z.b. smilies werden dann auch über https eingebunden und diejenigen die per http die Seite aufrufen bekommen dann Fehlermeldungen weil das https nicht sicher verifiziert ist. Diese Diskussion findet sich auch irgendwo hier im Feedback wieder.

[RalphS]

Ja natürlich nicht, das Zertifikat ist ja auch seit 2010 abgelaufen und wenn ein Zertifikat nicht gültig ist, dann kommt je nach Browser (oder allgemein Client) "irgendwas" bei raus - einschließlich "du darfst hier nicht zugreifen, Sicherheitsprobleme " und mit Pech kann man das dann auch nicht umgehen.

Das Grundproblem - nämlich die Performance - bleibt davon ja auch unberührt. Und wer weiß, ob nicht artfiles da noch was mitzureden hätte von wegen Auslastung; ganz zu schweigen davon daß man ja dann auch sehen müßte ob und ggf wieviel träger das System dadurch werden würde.

[Wiesel]

Nein. Weil das ein selbst ausgestelltes Zertifikat ist, gibt es, egal ob abgelaufen oder nicht immer eine Fehlermeldung dass der Zertifizierungsstelle nicht getraut werden kann. Und das finde schlimmer, da für User die von außerhalb kommen (Google etc) das ganze sehr unseriös aussieht.

[RalphS]

Nicht ganz. ALLES, was nicht zu einem Zertifikat in den "Vertrauenswürdigen Stammzertifizierungsstellen" verfolgt werden kann, ist per definition nicht vertrauenswürdig - also dahingehend, daß der Browser dann mosert.

Man kann das aber da rein tun. Dann wird "zwangsvertraut", in einem technischen Kontext. Deswegen sollte man das keinesfalls machen, wenn man dem Zertifikat nicht *real* vertraut.

- Wir müssen da natürlich überhaupt nicht drüber diskutieren. Self-signed auf einem öffentlichen Angebot? Geht nicht. Fertig. Aus.

[Ludacris]

ja nur wenn du dem Zertifikat vertraust, ich tu es aber nicht, dann sehe ich eine Fehlermeldung.