Πώς μία θύρα διαμεσολαβητή μπορεί να δέχεται και HTTP και SOCKS

Ένας μικτός ακροατής διαμεσολαβητή μπορεί να δέχεται HTTP και SOCKS σε μία θύρα TCP, επειδή ο διακομιστής εξετάζει τα αρχικά byte του πρωτοκόλλου. Ο αριθμός θύρας δεν εκτελεί αυτή την αναγνώριση.

Ένα αίτημα διαμεσολαβητή HTTP ξεκινά με μια μέθοδο HTTP, όπως GET ή CONNECT. Ένας χαιρετισμός SOCKS ξεκινά με δυαδικά πεδία πρωτοκόλλου. Λογισμικό σχεδιασμένο για αυτές τις εισόδους μπορεί να δρομολογήσει τη σύνδεση στον κατάλληλο χειριστή.

Αυτό είναι ρητό χαρακτηριστικό της υλοποίησης. Ένας συνηθισμένος ακροατής HTTP του Squid δεν γίνεται μικτός επειδή η θύρα του αλλάζει σε 1080, και ένας ακροατής μόνο SOCKS δεν μαθαίνει HTTP από μια ρύθμιση του προγράμματος περιήγησης.

Το TLS προσθέτει άλλο ένα όριο: μια κρυπτογραφημένη σύνδεση διαμεσολαβητή ξεκινά με TLS, όχι με ορατή μέθοδο HTTP. Η υποστήριξή του στο ίδιο τελικό σημείο απαιτεί πρόσθετο σκόπιμο χειρισμό· η αναγνώριση απλού HTTP και SOCKS δεν αποδεικνύει αυτή την ικανότητα.

Χρησιμοποιήστε το πρωτόκολλο πελάτη που τεκμηριώνεται για το τελικό σημείο. Αν λειτουργούν και τα δύο, αυτό είναι απόδειξη για τον μικτό ακροατή εκείνου του διακομιστή, όχι λόγος να αφήνετε το πρωτόκολλο απροσδιόριστο σε κάθε πελάτη.

Ο μικτός ακροατής του Glider δίνει ένα συγκεκριμένο παράδειγμα: κοιτάζει ένα byte χωρίς να το καταναλώνει, στέλνει το 0x05 στον χειριστή SOCKS5 του, και διαφορετικά καλεί τον αναλυτή HTTP του. Αυτός ο αναλυτής εξακολουθεί να επικυρώνει το εισερχόμενο αίτημα· η επιλογή αποστολής δεν κάνει μια αυθαίρετη είσοδο έγκυρο HTTP.

Ο διαμοιρασμός του ακροατή TCP δεν παρέχει από μόνος του συσχέτιση UDP του SOCKS5. Το Glider ξεκινά τον ακροατή UDP του ξεχωριστά. Η επιλογή πρωτοκόλλου TCP και η μεταγενέστερη αναμετάδοση datagram είναι ξεχωριστές ικανότητες.