Aussendienstanbindung
Bernd Hohmann
Dh. draussen rennen mehrere Leute mit ihren Laptops herum und tauschen
Daten mit der Zentrale aus.
Die Anwendung ist proprietär, die Sourcen liegen bei uns - wir sind also
völlig frei in der Gestaltung.
Die Sicherheitsanforderungen sind so streng nicht, mir macht eher das
Management der Zugänge sorgen.
Am schönsten wäre es natürlich, wenn es nur einen private Key und
mehrere public Keys geben könnte. Nach dem Ausscheiden des Mitarbeiters
deaktiviert man seinen Key und gut ist, für neue Mitarbeiter generiert
man einen passenden Key und aktiviert ihn.
Andere Variante wäre das über eine Benutzer/Kennwort-Liste abzuarbeiten
und zb. mit Blowfish zu verschlüsseln.
Ideen?
Bernd
--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean....@nixwill.de & bernado....@spammichvoll.de
Alexander Gran
> Am schönsten wäre es natürlich, wenn es nur einen private Key und
> mehrere public Keys geben könnte. Nach dem Ausscheiden des Mitarbeiters
> deaktiviert man seinen Key und gut ist, für neue Mitarbeiter generiert
> man einen passenden Key und aktiviert ihn.
Was spricht gegen ssh?
Grüße
Alex
Carsten Krueger
> Was spricht gegen ssh?
Oder OpenVPN, stunnel, etc.
Gru� Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://mailcatch.com/ - Antispam
cakruege (at) gmail (dot) com
Wolfgang Meiners
> Ich muss hier eine klassische Aussendienstanbindung machen.
ich denke, dass -fï¿œr kleinere Teams- svn zusammen mit ssh eine einfache
und gute Mï¿œglichkeit ist. Die Daten werden in einem zentralen Repository
verwaltet und stehen gleichzeitig unter Versionskontrolle. Nach
anfï¿œnglichem Checkout mï¿œssen sie auf den Mitarbeiterlaptops nur noch per
svn update synchronisiert werden. Verï¿œnderungen von Mitarbeitern sind
per svn commit in das zentrale Repository einspielbar und die
Aktualisierung kann -falls nï¿œtig- auch per ssh+svn beim Kunden erfolgen.
Das alles geht auch per Mausklick.
Geht ein Mitarbeiter, so wird sein ï¿œffentlicher ssh-Schlï¿œssel aus der
~/.ssh/authorized_keys gelï¿œscht und er hat keinen Zugriff mehr auf den
ssh-Server und damit auf das zentrale Reopsitory. Es muss auch nicht
jeder Mitarbeiter einen ssh-Account auf dem ssh-Server haben. Es reicht
ein ssh-Account in dessen ~/.ssh/authorized_keys die entsprechenden
ï¿œffentlichen Schlï¿œssel der Mitarbeiter gespeichert sind. ssh-Server gibt
es meines Wissens sogar fï¿œr Windows - allerdings nicht kostenfrei.
Soviel ich weiￜ, lￜuft svn auch unter Windows, obwohl ich Linux oder OSX
oder ein anderes Unix bevorzugen wï¿œrde.
Man sollte allerdings wissen, dass viele Leute heute eher zu
denzentralen Repositories raten, wie sie z.B. von Mercurial und Git
angeboten werden.
Grￜￜe
Wolfgang
Bernd Giegerich
> ssh-Server gibt es meines Wissens sogar fï¿œr Windows -
> allerdings nicht kostenfrei.
im Zweifelsfall halt cygwin mit OpenSSH.
> Soviel ich weiￜ, lￜuft svn auch unter Windows
jo, problemlos. Bei Bedarf auch mit Apache als Frontend (-> https mit
Auth gegen eine Windows Domain, Windows AD oder lokale Windows User).
Geht also auch ohne ssh.
Gruss,
Bernd
Bernd Hohmann
>> Was spricht gegen ssh?
>
> Oder OpenVPN, stunnel, etc.
Weil ich dazu vermutlich alle (Windows) Aussendienstlaptops einzeln
updaten darf (unser Updateprogramm fasst nur die eigene Software an) und
mir daher eine in unseren Code eingebaute Lösung sinniger erscheint.
Im Moment erscheint mir eine serverseitige Liste mit User/Keyfile und
Blowfish als am schnellsten zu implementieren.
Erhard Schwenk
> Ich muss hier eine klassische Aussendienstanbindung machen.
>
> Dh. draussen rennen mehrere Leute mit ihren Laptops herum und tauschen
> Daten mit der Zentrale aus.
>
> vï¿œllig frei in der Gestaltung.
>
> Die Sicherheitsanforderungen sind so streng nicht, mir macht eher das
>
> Am schï¿œnsten wï¿œre es natï¿œrlich, wenn es nur einen private Key und
> mehrere public Keys geben kï¿œnnte. Nach dem Ausscheiden des Mitarbeiters
> deaktiviert man seinen Key und gut ist, fï¿œr neue Mitarbeiter generiert
Du mï¿œchstest bitte Funktionsweise und Zusammenhï¿œnge von Private- und
Public Keys nochmal genau rekapitulieren.
Hint: man erzeugt fï¿œr jeden Mitarbeiter ein Schlï¿œsselpaar, den Private
Key kriegt er aufs Notebook, den Public Key benutzt man fï¿œr die
Zugriffssteuerung. Scheidet einer aus, schmeiï¿œt man dessen Public Key
aus der Zugriffssteuerung und weg ist er.
> Andere Variante wï¿œre das ï¿œber eine Benutzer/Kennwort-Liste abzuarbeiten
> und zb. mit Blowfish zu verschlï¿œsseln.
>
> Ideen?
Geht z.B. mit ipsec, l2tp, openvpn, pptpd, tinc oder einem SSH-Tunnel.
Am problemlosesten zu konfigurieren sind ssh, pptp und tinc, openvpn
kï¿œnnte interessant sein wenn man ï¿œber eine CA arbeiten will, ipsec ist
leider fï¿œrcherlich kompliziert weil jedes Gerï¿œt ein anders zum Rest der
Welt inkompatibles Subset implementiert.
--
Erhard Schwenk
Akkordeonjugend Baden-Wï¿œrttemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
Bernd Hohmann
>> Am schönsten wäre es natürlich, wenn es nur einen private Key und
>> mehrere public Keys geben könnte. Nach dem Ausscheiden des Mitarbeiters
>> deaktiviert man seinen Key und gut ist, für neue Mitarbeiter generiert
>> man einen passenden Key und aktiviert ihn.
>
> Du möchstest bitte Funktionsweise und Zusammenhänge von Private- und
> Public Keys nochmal genau rekapitulieren.
Das habe ich - darum frag ich ja. Denn rein aus der Überlegung heraus
müsste es Verfahren geben, die eine definierte Menge von Public Keys zu
einem Private Key erlauben.
Magnus Wagner
> Was spricht gegen ssh?
oder openvpn...
grüße
magnus
Bernd Eckenfels
> Am schï¿œnsten wï¿œre es natï¿œrlich, wenn es nur einen private Key und
> mehrere public Keys geben kï¿œnnte. Nach dem Ausscheiden des Mitarbeiters
> deaktiviert man seinen Key und gut ist, fï¿œr neue Mitarbeiter generiert
SSL mit Client Zertifikaten. Wenn Ihr die Sourcen habt ist es recht einfach
einen Socket mit einem SSLSocket zu wrappen. Und vor allem kann man auch
noch damit Werbung machen.
Gruss
Bernd
Richard W. Könning
>Erhard Schwenk schrieb:
>
>>> Am sch�nsten w�re es nat�rlich, wenn es nur einen private Key und
>>> mehrere public Keys geben k�nnte. Nach dem Ausscheiden des Mitarbeiters
>>> deaktiviert man seinen Key und gut ist, f�r neue Mitarbeiter generiert
>>> man einen passenden Key und aktiviert ihn.
>>
>> Du m�chstest bitte Funktionsweise und Zusammenh�nge von Private- und
>> Public Keys nochmal genau rekapitulieren.
>
>Das habe ich - darum frag ich ja. Denn rein aus der �berlegung heraus
>m�sste es Verfahren geben, die eine definierte Menge von Public Keys zu
>einem Private Key erlauben.
Ich kann Erhards Bitte nur beipflichten. Da es bei einem Schl�sselpaar
im Grunde egal ist, welchen von beiden Schl�sseln man privat und
welchen man �ffentlich nennt, folgt aus Deiner Forderung, da� es auch
eine Menge von Private Keys zu einem Public Key geben m�sste. Das
w�rde aber an den Signaturgrundlagen zumindestens kratzen.
Ciao,
Richard
--
Dr. Richard K�nning He�stra�e 63
Tel.: 089/5232488 80798 M�nchen
Bernd Hohmann
>>Das habe ich - darum frag ich ja. Denn rein aus der Überlegung heraus
>>müsste es Verfahren geben, die eine definierte Menge von Public Keys zu
>>einem Private Key erlauben.
>
> Ich kann Erhards Bitte nur beipflichten.
Wusste bislang noch gar nicht, dass Du und Erhard Kryptographieexperten
seit - danke für den Hint.
> Da es bei einem Schlüsselpaar im Grunde egal ist, welchen von beiden
> Schlüsseln man privat und welchen man öffentlich nennt,
Du schmeisst gerade alles über den Haufen, was ich bislang über
asymmetrische Kryptosysteme erarbeitet habe - erkläre mir, warum bei
einer Asymmetrie es egal ist, wer nun den privaten oder öffentlichen
Schlüssel hat?
> folgt aus Deiner Forderung, daß es auch eine Menge von Private Keys
> zu einem Public Key geben müsste. Das würde aber an den
> Signaturgrundlagen zumindestens kratzen.
Das eine hat mit dem anderen nichts zu tun.
Ich wollte nur wissen, ob es bereits Verfahren gibt, mit denen man die
Erzeugung des "private keys" so steuern kann, dass eine definierte Menge
"M" von passenden "public keys" herauskommt, auch wenn dadurch die
fiktive Sicherheit um den Faktor "M" verringert wird.
Wenn es das nicht gibt, mach ich halt traditionelles
Username/Schlüsselverfahren.
Bernd Eckenfels
> Ich wollte nur wissen, ob es bereits Verfahren gibt, mit denen man die
> Erzeugung des "private keys" so steuern kann, dass eine definierte Menge
> "M" von passenden "public keys" herauskommt, auch wenn dadurch die
> fiktive Sicherheit um den Faktor "M" verringert wird.
Du kannst sicher Gruppenschluessel generieren, das ist aber ein sehr hoher
Rechenaufwand der dir keinen Vorteil bringt. Erzeuge einfach fï¿œr jeden
Client ein Paar, dann kannst du jeden Client sperren indem du sein
ï¿œffentlichen Schlï¿œssel wegwirfst. Gï¿œngige SSL Server machen das ï¿œbrigens
selbst indem man ein Trust-Verzeichnis oder File angibt.
Denn Gruppenschlï¿œssel ist nichts was man mal eben so neu erfinden sollte.
Gruss
Bernd
Bernd Hohmann
>> Ich wollte nur wissen, ob es bereits Verfahren gibt, mit denen man die
>> Erzeugung des "private keys" so steuern kann, dass eine definierte Menge
>> "M" von passenden "public keys" herauskommt, auch wenn dadurch die
>> fiktive Sicherheit um den Faktor "M" verringert wird.
>
> Du kannst sicher Gruppenschluessel generieren, das ist aber ein sehr hoher
> Rechenaufwand der dir keinen Vorteil bringt.
Ok, danke für den Hinweis - dann ist das einfach gestorben.
> Erzeuge einfach für jeden Client ein Paar, dann kannst du jeden Client
> sperren indem du sein öffentlichen Schlüssel wegwirfst.
Ab dieser Ebene (wo dann eine 1:1 Verwaltung stattfinden muss) habe ich
massive Auswahl an Verschlüsselungsverfahren und da such ich mir einfach
eines aus, was sich am einfachsten an den Source kleben lässt und was
dem Auftraggeber fiktiv am sichersten erscheint.
Muss nur mal schauen was an vorhandenen Libs herumschlumpft und
problemlos mit Frage/Antwort-Spielchen klar kommt.
Bernd Eckenfels
> Ab dieser Ebene (wo dann eine 1:1 Verwaltung stattfinden muss) habe ich
> eines aus, was sich am einfachsten an den Source kleben lï¿œsst und was
Also sicher sind nur etablierte und verbreitete. IMHO kommst du eigentlich
nicht an alseits verfï¿œgbarn SSL Libs vorbei. Welche Programmiersprache denn?
Gruss
Bernd
Burkhard Ott
> ipsec ist
> leider fürcherlich kompliziert weil jedes Gerät ein anders zum Rest der
> Welt inkompatibles Subset implementiert.
Kan ich nicht bestätigen, alle meine Roadwarrior haben laufende IPSec
tunnel (x509 authentifiziert), geht einer updated ich die crl und
schmeiss die aufs gateway fertig.
Ja, es ist eine bunte Mischung aus Btriebssystemen, es ist alles dabei
Mac's Windows, Linux und 2 FreeBSD systeme.
cheers
Bernd Hohmann
>> Ab dieser Ebene (wo dann eine 1:1 Verwaltung stattfinden muss) habe ich
>> massive Auswahl an Verschlüsselungsverfahren und da such ich mir einfach
>> eines aus, was sich am einfachsten an den Source kleben lässt und was
>> dem Auftraggeber fiktiv am sichersten erscheint.
>
> Also sicher sind nur etablierte und verbreitete. IMHO kommst du eigentlich
> nicht an alseits verfügbarn SSL Libs vorbei. Welche Programmiersprache denn?
Wie mehrfach von mir beschrieben (auch in dem Quote, siehe da) geht es
nicht um die Qualität der Verschlüsselung sondern um Idiotensicherheit
(aka human failure) und schnell ausführbare Abschaltung eines Users bei
Kompromittierung.
Juergen P. Meier
Aber bitte nicht den gleichen Fehler begehen wie diese Idioten von
Apache oder Mickeysoft, und bei einem *definierten* Kontextwechsel
vergesseen, dass da gerade ein Kontext gewechselt wurde, beim
SSL-Kontextwechsel "renegotiation".
Oder wenigstens nicht wie alle auf TLS schieben, das kann da nix fuer,
wenn die Idioten der Apache Foundation so daemlich sind wie Mickeysoft
und das mit den Sicherheitskontexten verwechseln.
Arno Welzel
> Am schï¿œnsten wï¿œre es natï¿œrlich, wenn es nur einen private Key und
> mehrere public Keys geben kï¿œnnte. Nach dem Ausscheiden des Mitarbeiters
> deaktiviert man seinen Key und gut ist, fï¿œr neue Mitarbeiter generiert
> man einen passenden Key und aktiviert ihn.
OpenVPN wï¿œre da eine Lï¿œsung, gibt's auch mit grafischem Frontend fï¿œr
Windows im Systray.
Arno Welzel
[...]
> ï¿œffentlichen Schlï¿œssel der Mitarbeiter gespeichert sind. ssh-Server gibt
> es meines Wissens sogar fï¿œr Windows - allerdings nicht kostenfrei.
Mit Cygwin geht das auch unter Windows kostenfrei ;-)
Lutz Donnerhacke
> Richard W. K�nning schrieb:
>> Da es bei einem Schl�sselpaar im Grunde egal ist, welchen von beiden
>> Schl�sseln man privat und welchen man �ffentlich nennt,
>
> Du schmeisst gerade alles �ber den Haufen, was ich bislang �ber
> asymmetrische Kryptosysteme erarbeitet habe - erkl�re mir, warum bei
> einer Asymmetrie es egal ist, wer nun den privaten oder �ffentlichen
> Schl�ssel hat?
Bei RSA ist es tats�chlich egal, welcher Schl�ssel �ffentlich und welcher
privat verwendet wird. Allerdings wird �blicherweise der �ffentliche
Schl�ssel mit einem festen Exponenten generiert. Da die Exponentenkenntnis
das eigentliche Geheimnis ist, ist es eine schlechte Wahl, diesen "geheim"
zu halten.
Lutz Donnerhacke
> Wie mehrfach von mir beschrieben (auch in dem Quote, siehe da) geht es
> (aka human failure) und schnell ausf�hrbare Abschaltung eines Users bei
> Kompromittierung.
Dann nimm Window-Clients im AD, verteile Maschinenzertifikate per
domainenintegrieren Zertifikatsserver und baue die VPNs mit den Bordmitteln
von Windows aus.
Wenn die Kiste weg ist, sperre das Zertifikat.
Wenn der Nutzer das Passwort vergeigt, sperre den Nutzer.
Helmut Hullen
Du meintest am 16.11.09:
> Ich muss hier eine klassische Aussendienstanbindung machen.
> Dh. draussen rennen mehrere Leute mit ihren Laptops herum und
> tauschen Daten mit der Zentrale aus.
> Die Anwendung ist propriet�r, die Sourcen liegen bei uns - wir sind
> also v�llig frei in der Gestaltung.
Vielleicht komplett daneben: wie w�re es mit einem "Moodle"-Server in
der Zentrale? "Moodle" ist eigentlich konzipiert f�rs Fern-Lernen, aber
mindestens die meisten Komponenten, die Du vermutlich brauchst, sind
dort bereits eingebaut: eigener Account, eigenes Verzeichnis, Zugriff
(lesend und/oder schreibend) auf gemeinsame Dateien.
Und in der Oberfl�che so einfach, dass nicht nur Sch�ler damit
zurechtkommen, sondern sogar Lehrer.
Viele Gruesse!
Helmut
Marc Haber
>Bernd Hohmann schrieb:
>> Am schönsten wäre es natürlich, wenn es nur einen private Key und
>> mehrere public Keys geben könnte. Nach dem Ausscheiden des Mitarbeiters
>> deaktiviert man seinen Key und gut ist, für neue Mitarbeiter generiert
>
>Windows im Systray.
Braucht aber Adminrechte, oder ist das inzwischenv vorbei?
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Marc Haber
>Die Sicherheitsanforderungen sind so streng nicht, mir macht eher das
>Management der Zugänge sorgen.
Warum? Jeder Außendienstler sein Passwort, dann noch die Verbindung
verschlüsseln und fertig.
Bernd Hohmann
>>Die Sicherheitsanforderungen sind so streng nicht, mir macht eher das
>>Management der Zugänge sorgen.
>
> Warum? Jeder Außendienstler sein Passwort, dann noch die Verbindung
> verschlüsseln und fertig.
Hätte ja sein können dass es eine noch primitivere Variante gibt :-)
Carsten Krueger
> Weil ich dazu vermutlich alle (Windows) Aussendienstlaptops einzeln
> updaten darf (unser Updateprogramm fasst nur die eigene Software an) und
http://wpkg.org/ oder andere �hnliches.
Ihr m�sst doch irgendeine L�sung haben wie ihr die Rechner managed.
> mir daher eine in unseren Code eingebaute L�sung sinniger erscheint.
Die Chance auf sicherheitskritische Bugs ist dabei sehr wahrscheinlich
gr��er.
Carsten Krueger
> Mit Cygwin geht das auch unter Windows kostenfrei ;-)
Wenn's etwas schlanker sein darf (steckt aber auch Cygwin drin):
http://www.itefix.no/i2/copssh
Carsten Krueger
> Braucht aber Adminrechte, oder ist das inzwischenv vorbei?
Nein, die einzige Alternative wird anscheinend nicht weiterentwickelt.
http://openvpn.jowisoftware.de/
Die OpenVPN-Entwicklung selbst bleibt ja auch weiterhin grauslich.
Arno Welzel
> Arno Welzel <use...@arnowelzel.de> wrote:
>> Bernd Hohmann schrieb:
>>> Am sch�nsten w�re es nat�rlich, wenn es nur einen private Key und
>>> mehrere public Keys geben k�nnte. Nach dem Ausscheiden des Mitarbeiters
>>> deaktiviert man seinen Key und gut ist, f�r neue Mitarbeiter generiert
>>> man einen passenden Key und aktiviert ihn.
>> OpenVPN w�re da eine L�sung, gibt's auch mit grafischem Frontend f�r
>> Windows im Systray.
>
> Braucht aber Adminrechte, oder ist das inzwischenv vorbei?
Mit etwas Handarbeit geht das auch ohne Adminrechte. OK, einrichten muss
man es nat�rlich als Admin.
<http://openvpn.se/files/howto/openvpn-howto_run_openvpn_as_nonadmin-Rev1.1.html>
Christian Stubbs
> H�tte ja sein k�nnen dass es eine noch primitivere Variante gibt
Hm, VPN �ber LogMeIn / hamachi?
Richard W. Könning
>Richard W. K�nning schrieb:
>
>>>Das habe ich - darum frag ich ja. Denn rein aus der �berlegung heraus
>>>m�sste es Verfahren geben, die eine definierte Menge von Public Keys zu
>>>einem Private Key erlauben.
>>
>> Ich kann Erhards Bitte nur beipflichten.
>
>Wusste bislang noch gar nicht, dass Du und Erhard Kryptographieexperten
>seit - danke f�r den Hint.
Dein nachfolgender Absatz l��t jedenfalls erkennen, da� mindestens im
Vergleich zu Dir wir Kryptographieexperten sind. Jedenfalls habe ich
mich schon vor drei�ig Jahren mit dem Thema besch�ftigt.
>> Da es bei einem Schl�sselpaar im Grunde egal ist, welchen von beiden
> > Schl�sseln man privat und welchen man �ffentlich nennt,
>
>Du schmeisst gerade alles �ber den Haufen, was ich bislang �ber
>asymmetrische Kryptosysteme erarbeitet habe - erkl�re mir, warum bei
>einer Asymmetrie es egal ist, wer nun den privaten oder �ffentlichen
>Schl�ssel hat?
Die Asymmetrie besteht darin, da� man den einen Schl�ssel zum privaten
und den anderen zum �ffentlichen erkl�rt. Welcher der �ffentliche
Schl�ssel wird, ist im Grunde egal; zumindestens bei RSA, das ich im
weiteren Verlauf als Grundlage verwende. Aus Performance-Gr�nden gibt
man allerdings einen m�glichst kleinen Verschl�sselunsgs-Exponenten
mit m�glichst wenigen 1-Bits vor. Verschl�sseln und Signieren ist der
gleiche Algorithmus, nur da� er einmal mit einem �ffentliche
verbreiteten Schl�ssel und einmal mit einem geheim gehaltenen
durchgef�hrt wird.
Wenn n der Modulus mit n = p * q ist, dann gilt f�r den �ffentlichen
Exponenten e und den privaten Exponenten d:
e * d = 1 mod (p-1)*(q-1)
Da aber die Multiplikation von ganzen Zahlen kommutativ ist, gilt
genauso
d * e = 1 mod (p-1)*(q-1)
d.h. d und e sind symmetrisch.
>> folgt aus Deiner Forderung, da� es auch eine Menge von Private Keys
> > zu einem Public Key geben m�sste. Das w�rde aber an den
> > Signaturgrundlagen zumindestens kratzen.
>
>Das eine hat mit dem anderen nichts zu tun.
Nat�rlich hat das miteinander was zu tun. Signieren ist "Verschl�sseln
mit dem privaten Schl�ssel". Und da man voraussetzt, da� *der* private
Schl�ssel nur einer bestimmten Person bekannt ist, folgt man aus einer
erfolgreichen Entschl�sselung mit dem �ffentlichen Schl�ssel (auch
Verifizierung genannt), da� die Verschl�sselungsaktion von genau
dieser einen Person durchgef�hrt wurde. Wenn es allerdings mehrere
private Schl�ssel g�be, deren Verschl�sselungen mit dem gleichen
�ffentlichen Schl�ssel entschl�sselt werden k�nnten, dann w�re imho
das Signaturkonzept schon etwas angekratzt.
>Ich wollte nur wissen, ob es bereits Verfahren gibt, mit denen man die
>Erzeugung des "private keys" so steuern kann, dass eine definierte Menge
>"M" von passenden "public keys" herauskommt, auch wenn dadurch die
>fiktive Sicherheit um den Faktor "M" verringert wird.
Der erweiterte Euklidische Algorithmus f�hrt bei gegebenem e zu genau
einem d, und daran wird sich so schnell nichts �ndern ;-).
Richard W. Könning
>Bernd Eckenfels <bern...@eckenfels.net>:
>>
>> SSL mit Client Zertifikaten. Wenn Ihr die Sourcen habt ist es recht einfach
>> einen Socket mit einem SSLSocket zu wrappen. Und vor allem kann man auch
>> noch damit Werbung machen.
>
>Aber bitte nicht den gleichen Fehler begehen wie diese Idioten von
>Apache oder Mickeysoft, und bei einem *definierten* Kontextwechsel
>vergesseen, dass da gerade ein Kontext gewechselt wurde, beim
>SSL-Kontextwechsel "renegotiation".
>
>Oder wenigstens nicht wie alle auf TLS schieben, das kann da nix fuer,
>wenn die Idioten der Apache Foundation so daemlich sind wie Mickeysoft
>und das mit den Sicherheitskontexten verwechseln.
TLS kann sehr wohl etwas daf�r. Man kann lange RFC-Exegese betreiben,
um festzustellen, was genau TLS versprochen hat. M�glicherweise kommt
dann heraus, da� TLS weniger versprach, als die Leute annahmen und
*ben�tigten*, so das zun�chst die TLS-Anwender die Schuld h�tten.
Dennoch sollte man unabh�ngig von der Schuldfrage bei TLS nachbessern.
Bernd Hohmann
>> Hätte ja sein können dass es eine noch primitivere Variante gibt
>
> Hm, VPN über LogMeIn / hamachi?
Ich hab mir das gerade mal in der Praxis überlegt - eigentlich coole
Sache. Vielleicht noch paar TOR Strecken dazwischenschalten :-)
Bernd Hohmann
>>Wusste bislang noch gar nicht, dass Du und Erhard Kryptographieexperten
>>seit - danke für den Hint.
>
> Dein nachfolgender Absatz läßt jedenfalls erkennen, daß mindestens im
> Vergleich zu Dir wir Kryptographieexperten sind. Jedenfalls habe ich
> mich schon vor dreißig Jahren mit dem Thema beschäftigt.
Ich verneige mich vor Dir und Erhard und bedanke mich für eure Vorträge.
Bernd
Bernd Hohmann
>> Wie mehrfach von mir beschrieben (auch in dem Quote, siehe da) geht es
>> nicht um die Qualität der Verschlüsselung sondern um Idiotensicherheit
>> (aka human failure) und schnell ausführbare Abschaltung eines Users bei
>> Kompromittierung.
>
> Dann nimm Window-Clients im AD, verteile Maschinenzertifikate per
> domainenintegrieren Zertifikatsserver und baue die VPNs mit den Bordmitteln
> von Windows aus.
>
> Wenn die Kiste weg ist, sperre das Zertifikat.
> Wenn der Nutzer das Passwort vergeigt, sperre den Nutzer.
Klingt so gut dass ich das jetzt als primären Lösungsvorschlag nehme.
Vorteil: es ist Windows-Only und ich habe die Konfiguration aus den
Kreuz - darum soll sich der Admin kümmern der nach Sicherheit schreit.
Wenn die es nicht gebacken bekommen, ziehen wir den Kram in die
Anwendung rein (an die Mitarbeiterstammdaten nochmal einen Key
dranzupappen ist jetzt weniger das Problem und so hader viel Daten
müssen das nicht geschaufelt werden).
Danke,
Lutz Donnerhacke
> Lutz Donnerhacke schrieb:
>> Dann nimm Window-Clients im AD, verteile Maschinenzertifikate per
>> domainenintegrieren Zertifikatsserver und baue die VPNs mit den Bordmitteln
>> von Windows aus.
>>
>> Wenn die Kiste weg ist, sperre das Zertifikat.
>> Wenn der Nutzer das Passwort vergeigt, sperre den Nutzer.
>
Unser prim�rer L�sungsansatz.
> Wenn die es nicht gebacken bekommen,
schreibst Du mir 'ne Mail und bittest um ein Angebot.
Marc Haber
>Marc Haber schrieb:
>>>Die Sicherheitsanforderungen sind so streng nicht, mir macht eher das
>>>Management der Zugänge sorgen.
>>
>> Warum? Jeder Außendienstler sein Passwort, dann noch die Verbindung
>> verschlüsseln und fertig.
>
>Hätte ja sein können dass es eine noch primitivere Variante gibt :-)
Wie könnte die denn aussehen?
Bernd Hohmann
>>> Warum? Jeder Außendienstler sein Passwort, dann noch die Verbindung
>>> verschlüsseln und fertig.
>>
>>Hätte ja sein können dass es eine noch primitivere Variante gibt :-)
>
> Wie könnte die denn aussehen?
Gruppenschlüssel mit der Möglichkeit, einen einzelnen Key abzuklemmen.
Dann hätte ich auf dem Server weniger Keys zu verwalten.
Defacto biete ich jetzt den Ansatz von Lutz an (für den Fall, dass die
ihre Aussendienstmitarbeiter "richtig" einbinden wollen) oder
Username/Password mit Blowfish dazwischen (wenn der Austausch der paar
proprietären täglichen Datensätze unseres Systems langt).
Dr. Rainer Meergans
> Defacto biete ich jetzt den Ansatz von Lutz an (fï¿œr den Fall, dass die
> ihre Aussendienstmitarbeiter "richtig" einbinden wollen) oder
> Username/Password mit Blowfish dazwischen (wenn der Austausch der paar
> proprietï¿œren tï¿œglichen Datensï¿œtze unseres Systems langt).
>
Warum wollt ihr hier eigentlich alle das Rad neu erfinden? Mit OpenVPN
kannst Du eine eigene "Zertifzierungstelle" aufbauen, Zertifikate
ausstellen und bei Bedarf minutenschnell wiederrufen, und hast eine
erprobte Lï¿œsung. Alleine die Gefahr bei einer eigenene Lï¿œsung
unbeabsichtigt Sicherheitsrisiken einzubauen erscheint mir groￜ.
Man kann auch mit der OpenVPN-GUI eingene Pakete packen, in der alle
Hï¿œkchen richtig gesetzt sind und die Zertifikate passend kopiert werden,
die der Nutzer nur installieren muￜ. Oder der Admin, Nutzer mit
Adminrechten auf dem Firmenlaptop, ich weiￜ nicht...
Gruￜ,
Rainer
PS: Im Linuxmagazin gab es dieses Jahr einen Artikel ï¿œber die Charite in
berlin (groï¿œe Universitï¿œtsklinik), die OpenVPN einsetzen, lohnt zu lesen.
Carsten Krueger
> <http://openvpn.se/files/howto/openvpn-howto_run_openvpn_as_nonadmin-Rev1.1.html>
Kein Username/Passwort-Login, kein Smartcard-Login
Lutz Donnerhacke
> Bernd Hohmann schrieb:
>> ihre Aussendienstmitarbeiter "richtig" einbinden wollen) oder
>
Die Frage ist lustig, denn ein Vorschlag ist je genau:
a) die standardisierte und interopererable Protokollfamilie zu nehmen,
die f�r diese Aufgabe entwickelt wurde.
b) die Implementationen zu nehmen, die den System standardm��ig beiliegen und
vom Betriebssystemhersteller auch sauber in die Prozesse des Systems
integriert worden.
c) die passende Authentisierung zu nehmen, Zertifikate f�r Maschinen und
wechselnde Passworte f�r Nutzer.
d) das Schl�sselmanagement da anzusiedeln, wo sowieso diese Keys schon jetzt
verwaltet werden und Aktualisierungen vollautomatisch sauber funktionieren.
Stattdessen empfielst Du die Installation einer Fremdsoftware, die nur
deswegen funktioniert, weil es die einzige Implementation ist, die das
Prokoll spricht. Au�erdem ist die Integration ... bescheiden.
Lutz Donnerhacke
>> Defacto biete ich jetzt den Ansatz von Lutz an (f�r den Fall, dass die
>> ihre Aussendienstmitarbeiter "richtig" einbinden wollen) oder
>
Die Frage ist lustig, denn mein Vorschlag ist ja genau:
a) die standardisierte und interopererable Protokollfamilie zu nehmen,
die f�r diese Aufgabe entwickelt wurde.
b) die Implementationen zu nehmen, die den System standardm��ig beiliegen und
vom Betriebssystemhersteller auch sauber in die Prozesse des Systems
integriert worden.
c) die passende Authentisierung zu nehmen, Zertifikate f�r Maschinen und
wechselnde Passworte f�r Nutzer.
d) das Schl�sselmanagement da anzusiedeln, wo sowieso diese Keys schon jetzt
verwaltet werden und Aktualisierungen vollautomatisch sauber funktionieren.
Stattdessen empfielst Du die Installation einer Fremdsoftware, die nur
deswegen funktioniert, weil es die einzige Implementation ist, die das
Protokoll spricht. Au�erdem ist die Integration ... bescheiden.
Dr. Rainer Meergans
>> Warum wollt ihr hier eigentlich alle das Rad neu erfinden? Mit OpenVPN
>
> Die Frage ist lustig, denn ein Vorschlag ist je genau:
> a) die standardisierte und interopererable Protokollfamilie zu nehmen,
> die f�r diese Aufgabe entwickelt wurde.
�h, wollte der OP nicht das ganze in seine (propriet�re?) Anwendung
integrieren?
Wenn man das mit Windows-Bordmitteln (das meinst Du doch mit Deiner
etwas komplizierten Antwort?) geht, gerne.
Gru�,
Rainer
Bernd Hohmann
> Äh, wollte der OP nicht das ganze in seine (proprietäre?) Anwendung
> integrieren?
Nur weil etwas OSS ist, bedeutet das noch lange nicht dass es gut
integrierbar ist.
Marc Haber
>Marc Haber schrieb:
>>>> Warum? Jeder Außendienstler sein Passwort, dann noch die Verbindung
>>>> verschlüsseln und fertig.
>>>
>>>Hätte ja sein können dass es eine noch primitivere Variante gibt :-)
>>
>> Wie könnte die denn aussehen?
>
>Gruppenschlüssel mit der Möglichkeit, einen einzelnen Key abzuklemmen.
Das sieht nur primitiver aus.