Ένας ακροατής TLS forward proxy στο Squid 6.13

Το Squid 6.13 μπορεί να δέχεται αιτήματα forward proxy μέσω TLS όταν έχει μεταγλωττιστεί με GnuTLS ή OpenSSL. Αυτό προστατεύει τον σύνδεσμο πελάτη–proxy χωρίς παρεμβολή στην ξεχωριστή συνεδρία του προορισμού HTTPS.

1. Αποκτήστε πιστοποιητικό για το όνομα υπολογιστή που θα χρησιμοποιούν οι πελάτες για το Squid. Περιορίστε το ιδιωτικό κλειδί στις ταυτότητες υπηρεσίας που το χρειάζονται.
2. Προσθέστε ακροατή TLS με την εκχωρημένη διεύθυνση και τις πραγματικές διαδρομές πιστοποιητικών:

https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Διατηρήστε τη λίστα επιτρεπόμενων πελατών και τους περιορισμούς προορισμού καθώς και την πολιτική αυθεντικοποίησης. Ο ακροατής δεν παρέχει πρόσβαση. Διατηρεί επίσης ενεργό ένα υπάρχον http_port· αφαιρέστε ή περιορίστε τον παλιό ακροατή αν όλες οι συνδέσεις πελατών πρέπει να χρησιμοποιούν TLS. Δεν χρειάζεται λειτουργία επιταχυντή, παρεμβολής ή παραγωγής πιστοποιητικών.

Αναλύστε τη διαμόρφωση πριν επαναφορτώσετε την προβλεπόμενη υπηρεσία. Ο έλεγχος του αναλυτή επικυρώνει δομή και φόρτωση πιστοποιητικών, όχι προσβασιμότητα δικτύου. Μετά από επιτυχή επαναφόρτωση, στείλτε αίτημα μέσω του τελικού σημείου TLS από επιτρεπόμενο πελάτη:

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

Χρησιμοποιήστε το πραγματικό όνομα proxy και το εγκεκριμένο αρχείο CA. Ένα δημόσια έμπιστο πιστοποιητικό proxy μπορεί να μη χρειάζεται προσαρμοσμένη δέσμη. Το --proxy-cacert ρυθμίζει την εμπιστοσύνη του proxy και αφήνει ξεχωριστή την επαλήθευση προορισμού· κρατήστε και τους δύο ελέγχους.

Εξετάστε τον πραγματικό ακροατή και το όνομα πιστοποιητικού και δοκιμάστε επίσης ελεγχόμενη πηγή που πρέπει να απορριφθεί. Η επιτυχής ανάλυση από μόνη της δεν επιβεβαιώνει την εμπιστοσύνη πελάτη ή το όριο πρόσβασης.