Squid SSL - https_port Probleme bei der Sperrlistenüberprüfung (VERIFY_CRL)

[spooky_dizzy]

Hallo Leute,

Ich habe folgendes Problem:

Ich möchte meinen Squid (2.7) gerne SSL-Offloading machen sowie "aufschlagende" Nutzer per Client-Zertifikat überprüfen.
Zusätzlich sollen die Clientzertifikate gegen eine Sperrliste geprüft werden (CRL)
Leider kann ich keine höhere Version als 2.7 verwenden, da mir diese Squid-Version so vorgegeben ist.


Folgendes funktioniert bereits:

- Präsentieren / Validieren des Serverzertifikats (SSL-Offload)
- Prüfen des Client-Zertifikats gegen seine übergeordnete CA
- man bekommt die aufzurufende Seite auf dem Zielwebserver zu sehen

Hierzu die entsprechende Zeile in der suid.conf:


https_port 443 \
accel \
cert=/etc/ssl/servercerts/ServerCert.pem \
key=/etc/ssl/servercerts/ServerKey.pem \
version=1 \
options=ALL,NO_SSLv2 \
clientca=/etc/squid/clientca \
cafile=/etc/squid/clientca \
capath=/etc/ssl/certs/ \
sslflags=NO_DEFAULT_CA


Problem:
Leider hapert es mit der Sperrlistenüberprüfung.
Sobald ich gemäß
http://www.squid-cache.org/Versions/v2/2.7/cfgman/https_port.html
folgende Optionen hinzu nehme:


# crlfile=/etc/squid/crlfile123.pem
# sslflags=NO_DEFAULT_CA,VERIFY_CRL
# sslcontext=id

kann ich zwar noch die Pin für das Zertifikat angeben, bekomme aber die Seite nicht mehr zu sehen.
Meine vermutung ist - bzw. ich bin mir sicher, daß nun irgendwie das Clientzertifikat nicht mehr akzeptiert wird, da dessen Überprüfung fehlschlägt.
Sicher ist, daß das verwendete Zertifikat gültig und NICHT in der Sperrliste aufgeführt ist.

squid -v ergibt Folgendes:


Squid Cache: Version 2.7.STABLE5
configure options: '--prefix=/usr' '--sysconfdir=/etc/squid' '--bindir=/usr/sbin' '--sbindir=/usr/sbin' '--localstatedir=/var' '--libexecdir=/usr/sbin' '--datadir=/usr/share/squid' '--mandir=/usr/share/man' '--with-dl' '--with-maxfd=4096' '--with-valgrind-debug' '--enable-snmp' '--enable-carp' '--enable-auth=basic digest negotiate ntlm' '--enable-basic-auth-helpers=LDAP MSNT NCSA PAM SMB YP getpwnam multi-domain-NTLM' '--enable-ntlm-auth-helpers=SMB fakeauth no_check' '--enable-digest-auth-helpers=ldap password' '--enable-external-acl-helpers=ip_user ldap_group session unix_group wbinfo_group' '--enable-ntlm-fail-open' '--enable-arp-acl' '--enable-htcp' '--enable-underscores' '--enable-stacktraces' '--enable-delay-pools' '--enable-useragent-log' '--enable-referer-log' '--enable-forward-log' '--enable-multicast-miss' '--enable-ssl' '--enable-cache-digests' '--enable-auth-on-acceleration' '--enable-storeio=aufs,coss,diskd,null,ufs' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-icmp' '--with-samba-sources=/usr/include/samba' '--enable-large-cache-files' '--enable-x-accelerator-vary' '--enable-follow-x-forwarded-for' 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIE -DLDAP_DEPRECATED -fno-strict-aliasing' 'LDFLAGS=-pie'


Hat irgendwer von Euch eine Idee oder einen Rat, wo der Fehler liegen könnte?

Ach ja - und kann mir irgendwer von Euch sagen, was zum Henker dieser "sslcontext" ist? Ich bin mir hier leider nicht sicher, da ich diese Zeile auch nur so bei Papa Google gefunden habe. ^^

Vielen Dank für Eure Hilfe schon mal im Voraus :-)

LG spooky

[Thorashh]

Moin

Steht in der CRL mindestens ein gültiges widerrufenes Zertifikat?

Thorashh

[spooky_dizzy]

Hallo Thorashh,

in der CRL stehen eine Menge Seriennummern von widerrufenen Zertifikaten drin. Leider wissen mein Kollege und ich nicht, ob davon jetzt eines noch gültig ist ... und vor allem - wem es gehört :-) . Wir hatten daher auch schon die Idee, eines unserer Zertifikate mal sperren zu lassen. (das passiert dann wohl im Laufe des morgigen Tages)

Allerdings ist uns vorhin noch Folgendes eingefallen:

Im Zertifikat steht die Adresse für den Sperrlistenabruf ja drin. Demnach müßte man ja - völlig unabhängig davon, ob der Abruf nun ein verwertbares Ergebnis liefet - per tcpdump wenigstens einen Verbindungsaufbau an die IP des Sperrlistenservers sehen.
Gedacht ... und mal schnell vor Feierabend noch umgesetzt ...
Um sicher zu gehen, daß auch die richtige IP genommen wird, habe ich dem Squid sämtliche DNS-Informationen "geklaut", so daß er nur /etc/hosts kennt, die die Info (IP und Name - wie man es kennt) über den Sperrlistnserver beinhaltet. Ich habe sogar die /etc/resolv.conf auskommentiert ... das System hatte keinen DNS mehr - nur die /etc/hosts
Ergebnis:
man sieht auf dem Netzwerkinterface vom Squid-Server kein einziges Bit in Richtung Sperrlistenserver gehen, während das Serverzertifikat ausgeliefert und das Client-Zertifikat gegen seine Root-CA (PIN-Eingabe) erfolgreich geprüft wird. ... als ob der oben benannte Schalter

# sslflags=NO_DEFAULT_CA,VERIFY_CRL

dem Squid zwar ordnungsgemäß mitteilen würden, daß gegen eine Sperrliste zu prüfen ist, dem Squidi aber nun irgendetwas zu fehlen scheint, um erfolgreich einen Sperrlistenabruf zu tätigen. - vielleicht noch ein zu setzender Parameter - oder ein Modul? *grübel* :-(

hmmm ... vielleicht würde das auch erklären, warum auch nichts passiert, wenn man ein lokales Sperrlisten-File angibt:
# crlfile=/etc/squid/crlfile123.pem


... klingt eigentlich völlig verrückt *gg* ... aber mir fällt nichts mehr ein.

LG. - spooky

[spooky_dizzy]

Hallo zusammen,

wir haben das Problem eingegrenzt und mehr oder weniger gelöst.
Wie so oft sind es die lieben Kleinigkeiten, die wieder für neue graue Haare verantwortlich sind *gg*

Hier der bisherige Stand der Dinge:

Wenn man hier:
http://www.squid-cache.org/Versions/v2/2.7/cfgman/https_port.html
ganz(!) genau nachliest, stolpert man über Folgendes:



capath= Directory containing additional CA certificates
and CRL lists to use when verifying client certificates.


Der Lerneffekt besteht hier darin, daß sich das "additional" wohl nur auf "CA Certificates" bezieht - jedoch nicht auf "CRL lists".

Nachdem wir eine CRL-Liste (im PEM-Format) unterhalb dieses Pfades abgelegt haben und ein c_rehash (SLES10) durchgeführt haben, funktionierte der CRL-Check gegen eine lokal abgelegte CRL-Liste (Ein gültiges - aber gesperrtes Zertifikat - wurde abgelehnt, ein gültiges und nicht gesperrtes Zertifikat geht durch).
Die in einem Zertifikat angegebene Sperrlistenquelle (URL) bemüht der Squid jedoch nicht von alleine.

Hier werden wir uns wohl dadurch behelfen, daß wir die aktuelle Sperrliste per LDAP beziehen werden und diese dann somit aktuell dem Squid lokal zur Verfügung gestellt wird.

Hier noch mal das funktionierende Code-Beispiel aus der squid.conf



https_port 443 \
accel \
cert=/etc/ssl/servercerts/osap.pkibw.bundeswehr.org-cert.pem \
key=/etc/ssl/servercerts/osap.pkibw.bundeswehr.org-key.pem \
version=1 \
options=ALL,NO_SSLv2 \
clientca=/etc/squid/clientca \
cafile=/etc/squid/clientca \
capath=/etc/ssl/certs/ \
sslflags=VERIFY_CRL



Funktionieren würde auch, wenn man weitere crlfiles angeben möchte, die Ergänzunmg des obigen Beispieles um den Schalter:



crlfile=/etc/ssl/certs/crlfile.pem


Wichtig hierbei ist, daß diese(s) file(s) im capath liegen (unter SLES10 ebend /etc/ssl/certs/) und danach ein "C_rehash" ausgeführt wird - so zumindest unser aktueller Erkenntnisstand ;-)


LG. - spooky