Tek Bir Proxy Bağlantı Noktası Hem HTTP Hem de SOCKS Nasıl Kabul Edebilir
Kasıtlı olarak karışık bir dinleyicinin HTTP ile SOCKS'i nasıl ayırt edebildiğini, normal tek protokollü bir dinleyicinin ise bunu yapamadığını açıklar.
Karışık bir proxy dinleyicisi tek bir TCP bağlantı noktasında HTTP ve SOCKS kabul edebilir çünkü sunucu ilk protokol baytlarını inceler. Bağlantı noktası numarası bu algılamayı yapmaz.
Bir HTTP proxy isteği GET veya CONNECT gibi bir HTTP yöntemiyle başlar. Bir SOCKS selamlaması ikili protokol alanlarıyla başlar. Bu girdiler için tasarlanmış yazılım, bağlantıyı uygun işleyiciye yönlendirebilir.
Bu, açık bir uygulama özelliğidir. Normal bir Squid HTTP dinleyicisi bağlantı noktası 1080'e değiştirildiği için karışık hale gelmez ve yalnızca SOCKS dinleyicisi tarayıcı ayarından HTTP öğrenmez.
TLS başka bir sınır ekler: şifrelenmiş bir proxy bağlantısı görünür bir HTTP yöntemiyle değil, TLS ile başlar. Bunu aynı uç noktada desteklemek ek kasıtlı işlem gerektirir; düz metin HTTP ve SOCKS'i tanımak bu yeteneği kanıtlamaz.
Uç nokta için belgelenmiş istemci protokolünü kullanın. İkisi de çalışıyorsa bu, o sunucunun karışık dinleyicisine dair bir kanıttır, protokolü her istemcide belirtilmemiş bırakmak için bir neden değildir.
Glider'ın karışık dinleyicisi somut bir örnek sunar: bir baytı tüketmeden ona bakar, 0x05'i kendi SOCKS5 işleyicisine gönderir ve aksi halde kendi HTTP ayrıştırıcısını çağırır. O ayrıştırıcı gelen isteği yine de doğrular; gönderme seçimi rastgele girdiyi geçerli HTTP yapmaz.
TCP dinleyicisini paylaşmak kendi başına SOCKS5 UDP ilişkisini sağlamaz. Glider UDP dinleyicisini ayrı başlatır. TCP protokolü seçimi ve sonraki datagram aktarımı ayrı yeteneklerdir.