SSL im Eigenbau ?

[Hanno]

Hallo,

Ich programmiere gerade einen Webshop und hatte Folgendes zum Thema Verschlüsselung vor, da ich nicht über einen SSL Server verfüge:
1.) Daten werden normal in einem Formular eingegeben
2.) Bei "Submit" werden Daten in Formular durch AES mit einem bestimmten Schlüssel chiffriert und gesandt
3.) Auf der nächsten Seite angekommen werden sie entschlüsselt und mit einem neuen Schlüssel wieder verschlüsselt und in die Datenbank eingetragen.
Ich habe mir gedacht, dass ich somit eine sehr hohe Sicherheit erziele. Was sagt ihr dazu ?
Gruß
Hanno

[Stefan Bach]

Hallo,

2.) Bei "Submit" werden Daten in Formular durch AES mit einem bestimmten Schlüssel chiffriert und gesandt

Was ist AES? Und wie willst du die Daten auf der Clientseite ohne HTTP over SSL verwenden zu wollen verschlüsseln? Mit JavaScript etwa? (Bitte sag jetzt nicht ja.)

Viele Grüße,

Stefan

[Christopher Schmidt]

So weit ich dich verstanden habe; meine Empfehlung:

Nimm doch das normale SSl. Das ist schon gut!

[Frank aus Ulm]

Hi, hallo

Nimm doch das normale SSl. Das ist schon gut!

Wenn ich nicht wüßte, dass es ein l (ell) ist und kein I ... aber darum ging es ja: der Bub hat kein SSL zur Verfügung (egal ob unterstützender Server oder Zertifikat) und er hat nicht vor, sich das zuzulegen. Oder?

Sein Problem (in fact) ist:

• die verschlüsselung der Daten an sich ist für sich selbst _vielleicht_ sicher
• die Verbindung zwischen User und Server (wo die Daten durch die Gegend gepustet werden) ist nicht sicher

Da kann ich Sven ganz und gar Recht geben. Humbug solch eine Idee.

Tschau, tschüß,
Frank

[Sven Rautenberg]

Moin!

Ich habe mir gedacht, dass ich somit eine sehr hohe Sicherheit erziele. Was sagt ihr dazu ?

Ich halte davon nichts.

Erstens hast du nicht die Vorteile, die eine SSL-Verbindung bietet:
1. Man muß sich nicht drum kümmern.
2. Der Benutzer sieht sofort, dass die Verbindung sicher ist.
3. Er wird beim Datensenden u.U. auch nicht extra darauf hingewiesen, dass die Daten unsicher versandt werden.

Alle diese Dinge hat dein System nicht. Es könnte also genausogut auch weggelassen werden - rein optisch tut das nichts zur Sache. Und du kannst hundertmal beteuern, dass deine Lösung sicher sei - das kann niemand ohne kryptologische Ausbildung nachprüfen. Du verbesserst deinen Shop also nicht, und viele Kunden werden sich wegen der mangelnden Verschlüsselung beim Kaufen zurückhalten.

Zweitens ist sicher, dass du Fehler machst. Du wirst dir potentiell also irgendeine Schwachstelle einbauen, oder irgendwas vergessen, so dass dein Schutz angreifbar oder gar wirkungslos wird.

Drittens: Wie ist die Performance denn so? Und wie kriegst du die Schlüssel hin? Du mußt dich schon irgendwie gut mit Cryptographie auskenne, um wirklich gute Zufallsquellen zu finden, um die Schlüssel zu generieren. Oder du nimmst ein asymmetrisches Public-Key-Verfahren (bedenke aber: PGP und GnuPG generieren für jede Nachricht einen symmetrischen Schlüssel und verschlüsseln den dann asymmetrisch - u.A. aus Performancegründen).

All diese Dinge sprechen extrem gegen Eigenbaulösungen. Zuallererst natürlich, dass es kein echtes SSL ist, und die nachgebaute Sicherheit von niemandem überprüft werden kann. Das wird dich aber vermutlich nicht davon abhalten, es dennoch zu versuchen, oder?

- Sven Rautenberg

[Hanno]

nein ich habe es noch nicht versucht, ich suche nur nach einer Lösung, wie ich meine Daten sicherer machen kann, ohne SSL zu benutzen, darum geht es mir nur. Die Speicherung in der Datenbank durch AES verschlüsselung wäre doch schonmal gut, oder ?
gruß
Hanno

[Frank aus Ulm]

Hi, hallo

Speicherung in der Datenbank durch AES verschlüsselung wäre doch schonmal gut,

sensitive Daten sollten immer verschlüsselt abgelegt werden ... 100%ige Sicherheit kann aber so oder so nie garantiert werden. ...

es löst aber dein Problem nicht, denn die Daten sind un(ge)sicher(t) bevor sie in der DB ankommen -> das ist der springende PunkT!

Was dir fehlt, ist das Verständnis der Technologie SSL .. am besten du liest dich mal etwas durch das Internet!

Tschau, tschüß,
Frank

[Philipp Hasenfratz]

Halihallo Hanno

Ich programmiere gerade einen Webshop und hatte Folgendes zum Thema Verschlüsselung vor, da ich nicht über einen SSL Server verfüge:

Sehr geehrter Kund(e|in),

Bedauerlicherweise muss die Geschäftsleitung Ihnen gestehen, dass das Geld für ein
SSL-Zertifikat nicht aufgebracht werden konnte. Die Technik hat speziell
für Sie ein Javascript-Sicherheitsmechanismus erstellt, nur leider, ..., haben Sie
Javascript deaktiviert :-(
Kein Javascript, keine Geschenke einkaufen. Ach ja, falls Sie dies dennoch möchten,
dürfen Sie natürlich auch unser Formular ohne Javascript und ohne Verschlüsselung
verwenden und dort Ihre Mastercard-Nummer im plain/text übermitteln.

Wir bedanken uns für Ihr Verständnis.

Mit freundlichen Grüssen

Der Vorstand, der lieber selber Donati einsteckt...

--- :-) ---

Äm, für SSL braucht man keinen Server, sondern ein Zertifikat und einen Webserver, der
dieses Protokoll unterstützt.

1.) Daten werden normal in einem Formular eingegeben
2.) Bei "Submit" werden Daten in Formular durch AES mit einem bestimmten Schlüssel chiffriert und gesandt

Du meinst wohl DES. Äm, für eine DES-Encryption braucht es ein Passwort, ein Passwort
das der Kunde bei der Bestellung eingeben soll? - Woher hat er dieses Passwort, bzw.
wenn er es selber eingibt, wie gelangt es zu dir? - Über E-Mail? - Nun ja, Schluss mit
Sicherheit, da bringt selbst ein 1024bit Schlüssel mit TripleDES nix mehr...

Ich habe mir gedacht, dass ich somit eine sehr hohe Sicherheit erziele. Was sagt ihr dazu ?

So wie du es Vorschlägst ist es IMHO unsicher. Schwachstelle: Passwort. Dieses muss
irgendwie von dir zum Kunden bzw. vom Kunden zu dir gelangen und da ist das Problem.
Du müsstest eine official/private-key Umsetzung erwägen, wo der Kunde sich den
öffentlichen Schlüssel auf der Website holen kann, die Formulardaten damit schiffriert
werden und mit demselben Schlüssel nicht mehr rückschiffrieren lassen, erst mit dem
nur von dir bekannten private-Key können sich die Formulardaten entschlüsseln lassen.
s. GnuPG oder PGP.

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo ...

Du meinst wohl DES. Äm, für eine DES-Encryption braucht es ein Passwort, ein Passwort

Äm, es gibt natürlich auch AES, da guckt man sich kurz in der MySQL Doku wegen eines
ganz anderen Problems rum und schon sticht einem dies in die Augen :-)

Advanced Encryption Standard, wenn ich mich grad noch recht erinnere.

Gut, aber ändern tut sich an der Lage dennoch nix.

Viele Grüsse

Philipp

[Hanno]

Und was soll ich nun ohne SSL machen ? Soweit wie ich das weiß hat einfach nicht jeder Anbieter eine SSL unterstützung.
Gruß
Hanno
PS: Aber es ist doch sicherer als würde ich es weglassen

[Stefan Bach]

Hallo,

Und was soll ich nun ohne SSL machen ? Soweit wie ich das weiß hat einfach nicht jeder Anbieter eine SSL unterstützung.

Wenn man etwas verkaufen will, dann sollte man schon das nötige Geld ausgeben um sich bei einem gescheiten Anbieter einen gescheiten Server zu holen.

PS: Aber es ist doch sicherer als würde ich es weglassen

Nein, eigentlich nicht. Wenn du den Anwendern Sicherheit vorgaukelst, obwohl sie eigentlich nicht existiert, dann würde ich dies eher als kontraproduktiv einschätzen.

Viele Grüße,

Stefan

[Christian Seiler]

Hallo Hanno,

PS: Aber es ist doch sicherer als würde ich es weglassen

Selbst wenn Dein System 100% dicht wäre, würde niemand bei Dir einkaufen. Die Sicherheit bringt Dir also gar nichts.

SSL ist nicht ohne Grund direkt in den Browser eingebaut. Und es gibt nicht ohne Grund das SSL-Symbol. (meist unten rechts in der Statusleist) Und die Browser geben nicht ohne Grund Informations- und Warnmeldungen zum Thema SSL uas. Und es gibt nicht ohne Grund SSL-Zertifikate.

Suche Dir einen Anbieter, der SSL unterstützt. Die Investition lohnt sich. (Oder Du lässt es ganz bleiben mit Verkaufen im Internet)

Viele Grüße,
Christian

[Carsten]

Hi Phillip,

So wie du es Vorschlägst ist es IMHO unsicher. Schwachstelle: Passwort. Dieses muss
irgendwie von dir zum Kunden bzw. vom Kunden zu dir gelangen und da ist das Problem.
Du müsstest eine official/private-key Umsetzung erwägen, wo der Kunde sich den
öffentlichen Schlüssel auf der Website holen kann, die Formulardaten damit schiffriert

Der öffentliche Schlüssel kann mit der Formular-Webseite und dem verschlüsselnden JavaScript mitgeschickt werden.

werden und mit demselben Schlüssel nicht mehr rückschiffrieren lassen, erst mit dem
nur von dir bekannten private-Key können sich die Formulardaten entschlüsseln lassen.
s. GnuPG oder PGP.

Das Verfahren ist damit sicher und wäre auch funktionsfähig. Allerdings hast du völlig recht: Der Kunde erwartet eine Lösung der er vertraut. Und da gehört selbstgestricktes nun mal nicht zu.

Gruss,
  Carsten

[Carsten]

Hallo,

kurzer Nachtrag:

Das Verfahren ist damit sicher und wäre auch funktionsfähig.

das stimmt nur bedingt: Das Verfahren ist nicht gegen 'Man in the middle' Attacken geschützt.

Carsten

[TomIRL]

Hallo Hanno,
Was sagt ihr dazu ?

Exotische Lösung, und ich würde nicht bei Dir einkaufen!
Ganz sicher nicht!
Schenbar hast Du die Funktionsweise von SSL nícht verstanden!

Viele Grüße TomIRL

[Tim Tepaße]

Hallo Hanno,

Ich habe mir gedacht, dass ich somit eine sehr hohe Sicherheit erziele. Was
sagt ihr dazu ?

Daß Du so gut wie überhaupt keine Sicherheit erziehltst. Und das liegt
nicht an der Verwendung von AES, sondern an Deinen grundsätzlichen
Konzeptionsmangeln. Sorry, daß ich so harsch klinge, anders ist es
aber nicht zu beurteilen.

Ich will versuchen, es zu erklären.

Du willst Daten (D) vom Browser (B) zum Server (S) zu übertragen, ohne daß
diese jemand (X) in der Mitte lesen kann.

D -> B --------------> S -> D    (Zeitpunkt t2)
              ^
              X

Dazu willst Du diese verschlüsseln und benutzt AES. Soweit so gut.
AES ist ein klassischer Blockchiffrealgorithmus, der zum Verschlüsseln
einen Schlüssel benötigt:

AES(Daten, Schlüssel) = Murks

Soweit, so sicher. Aber Dein Problem liegt schon vorher. Woher weiß der
Browser nämlich, daß er AES und welchen Schlüssel verwenden soll?
Dadurch, daß es in der Seite steht. Und da Du kein SSL zur Verfügung
hast, wird diese Seite unverschlüsselt übertragen.

Seite <- B <--------------- S <- Seite     (Zeitpunkt t1)
                  ^
                  X

Merkst Du was? Der potentielle Angreifer muß also nur das Senden der
Seite an den Browser abhören, in den (unverschlüsselten) Quelltext
gucken und feststellen, daß a) AES verwendet wird und b) welcher
Schlüssel verwendet wird.

Und schon hat er alle benötigten Daten, um die zum Zeitpunkt t2
versandten Daten wieder zu entschlüsseln, genauso wie der Server.

Dein Problem ist das altbekannte kryptographische Problem, der
Schlüssel zum entschlüsseln der verschlüsselten Botschaft zum
Sender bzw. Empfänger der Botschaft zu kriegen. Als Antwort
auf dieses Problem wurde das Public-Key-Verfahren entwickelt.

Dieses findet beispielsweise in PGP (bzw. GPG) seine Anwendung
und natürlich auch (Du ahnst es schon) in SSL.

Deswegen kann man Dir nur empfehlen: Verwende SSL. Es geht
einfach nicht anders, wenn man Sicherheit erreichen will.
Gerade bei so sensiblen Anwendungen wie einem Webshop.

• Tim

[Henryk Plötz]

Moin,

Ich programmiere gerade einen Webshop und hatte Folgendes zum Thema Verschlüsselung vor, da ich nicht über einen SSL Server verfüge:
1.) Daten werden normal in einem Formular eingegeben
2.) Bei "Submit" werden Daten in Formular durch AES mit einem bestimmten Schlüssel chiffriert und gesandt
3.) Auf der nächsten Seite angekommen werden sie entschlüsselt und mit einem neuen Schlüssel wieder verschlüsselt und in die Datenbank eingetragen.
Ich habe mir gedacht, dass ich somit eine sehr hohe Sicherheit erziele. Was sagt ihr dazu ?

Dass das Mist ist.

a) AES ist ein wunderschöner symmetrischer Algorithmus. Du musst also den gleichen Schlüssel zum Ver- wie auch Entschlüsseln benutzen. Zum Verschlüsseln musst du diesen Schlüssel an den Browser schicken. Damit ist der Schlüssel nicht mehr geheim und die Verschlüsselung vollständig und vollkommen hinfällig.
b) Dagegen gibt es asymmetrische Verfahren. Die haben aber eigentlich alle gemeinsam, dass du zum einen einen größeren Schlüssel brauchst und zum anderen (unter anderem wegen der großen Schlüssel) mit ekelhaft großen Zahlen hantieren musst. Das ist schon in herkömmlichen Programmiersprachen keine Freude und Aufwendig[0], aber in JavaScript quasi unmachbar[1].
c) Selbst wenn du einen asymmetrischen Algorithmus implementiert hast, werden das Programm, dass den Algorithmus ausführt und der Schlüssel weiterhin ungeschützt übertragen. Ein Angreifer kann relativ einfach deinen Schlüssel (oder wahlweise dein JavaScript) abfangen und durch eine Version ersetzen welche es ihm erlaubt, die verschlüsselten Daten mitzulesen.

Du erreichst also einerseits 0 (in Worten "null") Sicherheit und hast andererseits einen immensen Aufwand.

[0] Der durchschnittliche Integer hat 32 Bit. Ein RSA-Schlüssel hat (wenn er auch nur annähernd sicher sein soll) 1024 Bit.
[1] Ich habe in meiner BASIC-Zeit auch mal mit großen Zahlen in BASIC hantiert. Das hat beinahe eine Minute für eine popelige Potenz gebraucht (ok, der Exponent war ziemlich groß, 17088 glaube ich).

[Hanno]

Hallo,

Danke erstmal für diese vielen Antworten, doch ich habe noch etwas sehr wichtiges vergessen. Der Shop wird von mir an eine Webdesign Firma verkauft werden, welche wiederum den Shop auf den Systemem ihrer Kunden installiert. Ich will für den Fall, dass diese kein SSL haben, eine Alternative bereitstellen, darum geht es mir.
Gruß
Hanno

[TomIRL]

Hallo Hanno,

Danke erstmal für diese vielen Antworten, doch ich habe noch etwas sehr wichtiges vergessen. Der Shop wird von mir an eine Webdesign Firma verkauft werden, welche wiederum den Shop auf den Systemem ihrer Kunden installiert. Ich will für den Fall, dass diese kein SSL haben, eine Alternative bereitstellen, darum geht es mir.

Sehr lobenswert;
Aber es gibt IMHO keine Alternativen!
Es wäre möglich, dass die Kunden so ProxySSL Konzepte verwenden wie sie von 1und1 angeboten weden, also ohne eignes Zertifikat.
Das wäre das einzig sinnvolle und sichere.

Die grundsätzliche Frage ist immer, was muß überhaupt verschlüsselt werden?
Name und Adresse krieg ich aus jedem Telefonbuch oder für 50 EURO von einem Adressermittler.
Telefon und Fax Nummer, die ist ja auch nicht wirklich geheim.
Bankverbindung ? Steht auf jedem Briefbogen drauf.
Ist also auch nicht geheim.
Naja Kreditkarteninformationen die sind schon vor Mißbrauch zu schützen.
Aber dann sollte man zur eignen Sicherheit eh entsprechnde Clearingstellen und Sicherheitsdinge installieren.
Die Kosten für eine Rückbuchung eines Kredikartenkunden trägt nämlich der Shop und nicht etwa die Kreditkartenfirma.

Viele Grüße TomIRL

[Hanno]

Hallo,

Und was heißt das jetzt fürmich ?
Das ich die Verschlüselung ganz lassen sollte ( ich habe kein Kreditkarten-System implementiert ) ?
Bisher verschlüssle ich nur Passwörter mit MD5, da die mich ja nichts angehen. Die werden über javascript vor Formular-Abgabe verschlüsselt. Also soll ich es dabei lassen ?
Gruß
Hanno

[TomIRL]

Hallo,

Und was heißt das jetzt fürmich ?
Das ich die Verschlüselung ganz lassen sollte ( ich habe kein Kreditkarten-System implementiert ) ?

Tja die Frage kann ich Dir leider nicht beantworten!
Wie empfindlich sind die Kunden?
Davon hängt es ab was Du verschlüsseln mußt und was nicht.

Bisher verschlüssle ich nur Passwörter mit MD5, da die mich ja nichts angehen. Die werden über javascript vor Formular-Abgabe verschlüsselt. Also soll ich es dabei lassen ?

MD5 ist ausreichend, allerdings würde ich die Passwörter per PHP verschlüsseln.
Javaskript kann man abschalten und dann?

Gruß  TomIRL

übrigens auf http://www.verisign.de bekommste ein Tutorial zum Downlaod wie SSL und e-payment funktioniert.
Bloß zur Info für Dich kannste mal vor dem schlafen gehen lesen, ist alles sehr einfach erklärt.

[Hanno]

Ich kann die PAsswörter nur mit JavaScript verschlüsseln, da sie vor Form-Übergabe verschlüsselt werden sollen. Wenn ich sie erst a,m Ziel verschlüssle, wurden sie unverschlöüsselt übergeben, was genau ich ja nich will.
gruß
hanno

[Henryk Plötz]

Moin,

Ich kann die PAsswörter nur mit JavaScript verschlüsseln, da sie vor Form-Übergabe verschlüsselt werden sollen.

Dann nimm' HTTP Digest Authentication.

Wenn ich sie erst a,m Ziel verschlüssle, wurden sie unverschlöüsselt übergeben, was genau ich ja nich will.

Zum einen ist MD5 keine Verschlüsselung sondern eine Hashfunktion. Zum anderen trägt sie bei dieser Verwendung genau _nichts_ zur Sicherheit bei. Ein Angreifer der ein Klartextpasswort mitlauschen könnte, kann auch den Hash mitlauschen und anschließend wie das Kennwort benutzen. Du verlangst ja nirgendwo die Kenntnis des Kennworts, nur des Hashs.

Wenn du soetwas unbedingt machen musst, solltest du wenigstens(!) mit PHP eine zufällige Zahl (ein Timestamp tut es eventuell auch) als Challenge in das JavaScript reinschreiben und diese mit dem Kennwort mithashen. An den Server werden dann der Hash als Response und eine Kopie der Challenge übermittelt. Der überprüft dann, ob die Challenge neu genug ist[1] und verweigert gegebenenfalls den Zugang. Falls ein Angreifer die Response mitschneiden sollte, kann er sie nur solange benutzen wie die Challenge gültig ist. Der Gültigkeitszeitraum sollte also nicht zu lang sein. (5 Minuten müssten dicke ausreichen!) Man-in-the-middle-Angriffe lassen sich aber so immer noch nicht verhindern.

So ähnlich funktioniert auch HTTP Digest Authentication. Das hat allerdings noch Vorteile: Wenn eine Challenge ungültig wird sagt der Server das dem Browser und der wiederholt die Anfrage mit einer aktuellen Challenge ohne dass der Benutzer eingreifen müsste. Ausserdem werden noch mehr Infos mitgehasht, so dass Replay-Attacken sofort unmöglich werden können (ohne auf den Ablauf der Challenge zu warten) und Man-in-the-middle-Attacken weitgehend sinnlos werden, da eine Response nur genau eine Aktion authentifiziert. Und: Es ist im Browser eingebaut, ein offener Standard und daher in seinen Sicherheitsproblemen sicherlich besser untersucht.

[1] Bei Zufallszahlen müsstest du also alle ausgegebenen Zahlen - oder zumindest die von der letzten Zeit - und den Ausgabezeitpunkt auf dem Server zwischenspeichern.

[Hanno]

Wo finde ich denn die http digest asutehntication ?
Gruß
Hanno

[Henryk Plötz]

Moin,

Wo finde ich denn die http digest asutehntication ?

Indem du HTTP Digest Authentication (richtig geschrieben, versteht sich) in Google eingibst!?! Das leitet dich direkt zu RFC 2617, dem Standard der das beschreibt. Eine Implementierung findet sich zum Beispiel für den Apache in mod_digest oder besser mod_auth_digest.

Und ja, man kann das auch in PHP machen. Nein, das ist nicht vollständig trivial. Ich wäre bereit, fast fertigen Code dazu unter GPL abzugeben.

[Sven Rautenberg]

Moin!

Und was heißt das jetzt fürmich ?
Das ich die Verschlüselung ganz lassen sollte ( ich habe kein Kreditkarten-System implementiert ) ?

Richtig. Es macht die ganze Sache kompliziert, AES selbst (oder jeder andere symmetrische Mechanismus) trägt auch nichts zur Sicherheit bei, weil der Schlüssel irgendwie mit übertragen werden muß - und wenn man ihn kennt, kann man die Daten wieder entschlüsseln. Bringt also nichts.

Bisher verschlüssle ich nur Passwörter mit MD5, da die mich ja nichts angehen. Die werden über javascript vor Formular-Abgabe verschlüsselt. Also soll ich es dabei lassen ?

Das ist auch großer Quatsch. Wie werden die md5-Passwörter denn auf dem Server behandelt? Direkt als Zugangskriterium verwendet? Dann muß man also nur das verschlüsselte Passwort abfangen und unverändert an den Server senden, um Zugang zu erlangen. Das bringt keinerlei Sicherheit, die für den Zugang notwendigen Daten werden immer noch im Klartext übertragen.

Der Shop wird von mir an eine Webdesign Firma verkauft werden, welche wiederum den Shop auf den Systemem ihrer Kunden installiert. Ich will für den Fall, dass diese kein SSL haben, eine Alternative bereitstellen, darum geht es mir.

Sei mir nicht böse, aber deine bisherigen Aussagen zeigen, dass du von Sicherheit keinen wirklichen Schimmer hast.

Als Konsequenz daraus solltest du entweder Programmierungen lassen, bei denen es doch irgendwie auf Sicherheit ankommt, oder dir die notwendigen Kenntnisse über Sicherheit nach und nach aneignen.

Du hast schließlich eine hohe Verantwortung! Du sollst etwas schreiben, was eine Webdesign-Firma (hoffentlich mit vorheriger Qualitätskontrolle durch einen Mitarbeiter dort) ihren Kunden verkaufen will. Die Kunden wollen mit dem Shop Geld verdienen. Sie wollen nicht, dass Kunden aufgrund von Sicherheitsproblemen wegbleiben. Und natürlich auch nicht, dass Cracker ihnen die Seiten weghacken (das war aktuell schön bei Herrn Wölks Website zu beobachten: [pref:t=48684&m=265531]).

Bedenke, dass die Webdesign-Firma für ein mangelhaftes Produkt ihren Kunden gegenüber haftet - und du wahrscheinlich dann gegenüber der Webdesign-Firma. Denn für irgendwas muß die dich ja schließlich bezahlen - ansonsten hätten sie vermutlich einen der vielen Open-Source- oder Freeware-Shops genommen und ihren Kunden verkauft.

Du hast im Prinzip eigentlich nur zwei Möglichkeiten für einen Shop: Entweder machst du das übliche Shopverhalten mit Anzeige von Produkten, Warenkorb etc., und wenn's dann ans Bestellen geht, ist die klare Entscheidung des Shop-Anbieters, kein SSL zu verwenden, und als Konsequenz daraus kann das Bestellformular dann keine wichtigen, geheimzuhaltenden persönlichen Daten abfragen. Als weitere Konsequenz daraus kann man als Kunde möglicherweise nicht komplett online einkaufen, weil man die Zahlungsinformationen nicht übermitteln möchte. Bleibt also eigentlich nur Lieferung per Nachnahme oder per Rechnung. Zahlung per Lastschrift würde auch noch gehen (Lastschriften, auch von bösen Buben, kann man problemlos 6 Wochen lang bei seiner Bank zurückbuchen lassen - trotzdem würde ich meine private Kontoverbindung nicht ungesichert übers Netz versenden wollen). Kreditkartendaten fallen jedenfalls definitiv aus!

Die Alternative dazu ist ein SSL-Shop. Gerne auch von vorne bis hinten SSL. Inklusive aller Bilder, Shopping-Bewegungen und Warenkorb-Operationen. Wenn du nämlich teilweise Elemente einer Seite nur über HTTP lädst, dann gibt das so häßliche Warnmeldungen im Browser, dass nicht alle Elemente der Seite sicher seien.

Und mit SSL geht dann natürlich grundsätzlich alles, was an Daten zu übermitteln sein soll. Nur mache bitte dann nicht den Fehler und schreibe diese Daten dann in eine Benachrichtigungsmail an den Shop-Betreiber. Die ist dann nämlich wieder unverschlüsselt, und man kann sich das SSL-Gefrickel vorher im Prinzip dann auch sparen.

- Sven Rautenberg

[Hanno]

Hallo,

Ich habe noch eine Frage zu SSL. Da ich mich damit so gut wie garnicht auskenne, muss ich die blöde Frage stellen:
Wenn ich SSL verwende, müssen doch eigentlich alle Dateien des Shops ( zumindestens die PHP Dateien, die Templates und Bilder können ja woanders lagern ) auf dem SSL Server liegen, oder ?
Gruß
Hanno

[TomIRL]

garnicht auskenne, muss ich die blöde Frage stellen:

Wenn ich SSL verwende, müssen doch eigentlich alle Dateien des Shops ( zumindestens die PHP Dateien, die Templates und Bilder

Kommt drauf an wo die Bilder liegen!
Wenn die irgendwo auf dem Server liegen ja, nur nicht im http Bereich!
Die PHP müßen natürlich in dem Verzeichniss(meist ist es nur ein Verzeichniss) liegen.
VIele Grüße TomIRL