การบังหน้าโดเมนตาม TLS 1.3

การแนะนำ

ระบบกรองเนื้อหาองค์กรสมัยใหม่จากผู้ผลิตที่มีชื่อเสียงเช่น Cisco, BlueCoat, FireEye มีความเหมือนกันค่อนข้างมากกับระบบ DPI ที่ทรงพลังกว่าซึ่งกำลังดำเนินการอย่างแข็งขันในระดับชาติ สาระสำคัญของงานของทั้งสองคือการตรวจสอบการรับส่งข้อมูลอินเทอร์เน็ตขาเข้าและขาออก และตัดสินใจแบนการเชื่อมต่ออินเทอร์เน็ตโดยพิจารณาจากรายการขาวดำ และเนื่องจากทั้งสองคนอาศัยหลักการที่คล้ายคลึงกันในพื้นฐานของงาน วิธีการหลีกเลี่ยงสิ่งเหล่านั้นจึงมีอะไรเหมือนกันมากเช่นกัน

หนึ่งในเทคโนโลยีที่ช่วยให้คุณข้ามทั้ง DPI และระบบองค์กรได้อย่างมีประสิทธิภาพคือเทคโนโลยีการหันหน้าเข้าหาโดเมน สิ่งสำคัญคือเราไปที่ทรัพยากรที่ถูกบล็อก โดยซ่อนอยู่เบื้องหลังโดเมนสาธารณะที่มีชื่อเสียงที่ดี ซึ่งเห็นได้ชัดว่าจะไม่ถูกบล็อกโดยระบบใดๆ เช่น google.com

มีการเขียนบทความเกี่ยวกับเทคโนโลยีนี้ค่อนข้างมากและมีตัวอย่างมากมาย อย่างไรก็ตาม เทคโนโลยี DNS-over-HTTPS และ Encrypted-SNI ที่ได้รับความนิยมและมีการพูดคุยกันเมื่อเร็วๆ นี้ รวมถึงเวอร์ชันใหม่ของโปรโตคอล TLS 1.3 ทำให้พิจารณาตัวเลือกอื่นสำหรับการบังหน้าโดเมนได้

ทำความเข้าใจกับเทคโนโลยี

ขั้นแรก เรามากำหนดแนวคิดพื้นฐานเล็กน้อยเพื่อให้ทุกคนเข้าใจว่าใครเป็นใครและทำไมทั้งหมดนี้จึงจำเป็น เราได้กล่าวถึงกลไก eSNI ซึ่งจะมีการหารือเกี่ยวกับการดำเนินการต่อไป กลไก eSNI (การระบุชื่อเซิร์ฟเวอร์ที่เข้ารหัส) เป็นเวอร์ชันที่ปลอดภัยของ SNI ซึ่งใช้ได้เฉพาะกับโปรโตคอล TLS 1.3 เท่านั้น แนวคิดหลักคือการเข้ารหัสข้อมูลเกี่ยวกับโดเมนที่คำขอถูกส่งไปยัง

ตอนนี้เรามาดูกันว่ากลไก eSNI ทำงานอย่างไรในทางปฏิบัติ

สมมติว่าเรามีทรัพยากรอินเทอร์เน็ตที่ถูกบล็อกโดยโซลูชัน DPI ที่ทันสมัย ​​(ตัวอย่างเช่น rutracker.nl ตัวติดตามฝนตกหนักที่มีชื่อเสียง) เมื่อเราพยายามเข้าถึงเว็บไซต์ของตัวติดตามทอร์เรนต์ เราจะเห็นต้นขั้วมาตรฐานของผู้ให้บริการระบุว่าทรัพยากรถูกบล็อก:

บนเว็บไซต์ RKN โดเมนนี้จริง ๆ แล้วอยู่ในรายการหยุด:

เมื่อคุณค้นหา whois คุณจะเห็นว่าโดเมนนั้น "ซ่อน" อยู่ด้านหลังผู้ให้บริการคลาวด์ Cloudflare

แต่แตกต่างจาก "ผู้เชี่ยวชาญ" จาก RKN พนักงานที่เชี่ยวชาญด้านเทคนิคจาก Beeline (หรือสอนโดยประสบการณ์อันขมขื่นของหน่วยงานกำกับดูแลที่มีชื่อเสียงของเรา) ไม่ได้แบนไซต์อย่างโง่เขลาด้วยที่อยู่ IP แต่เพิ่มชื่อโดเมนลงในรายการหยุด คุณสามารถตรวจสอบสิ่งนี้ได้อย่างง่ายดายหากคุณดูว่าโดเมนอื่นใดที่ซ่อนอยู่หลังที่อยู่ IP เดียวกัน โปรดไปที่โดเมนใดโดเมนหนึ่งและดูว่าการเข้าถึงไม่ได้ถูกบล็อก:

สิ่งนี้เกิดขึ้นได้อย่างไร? DPI ของผู้ให้บริการรู้ได้อย่างไรว่าเบราว์เซอร์ของฉันเปิดโดเมนใด เนื่องจากการสื่อสารทั้งหมดเกิดขึ้นผ่านโปรโตคอล https และเรายังไม่เห็นการแทนที่ใบรับรอง https จาก Beeline เขาเป็นผู้มีญาณทิพย์หรือฉันกำลังถูกติดตาม?

ลองตอบคำถามนี้โดยดูที่การรับส่งข้อมูลผ่าน wireshark

ภาพหน้าจอแสดงว่าเบราว์เซอร์ได้รับที่อยู่ IP ของเซิร์ฟเวอร์ผ่าน DNS ก่อน จากนั้นจะมีการจับมือ TCP มาตรฐานกับเซิร์ฟเวอร์ปลายทาง จากนั้นเบราว์เซอร์จะพยายามสร้างการเชื่อมต่อ SSL กับเซิร์ฟเวอร์ ในการดำเนินการนี้ ระบบจะส่งแพ็กเก็ต Hello Client SSL ซึ่งมีชื่อของโดเมนต้นทางในรูปแบบข้อความธรรมดา เซิร์ฟเวอร์ส่วนหน้าของ cloudflare จำเป็นต้องกรอกข้อมูลในช่องนี้เพื่อกำหนดเส้นทางการเชื่อมต่อได้อย่างถูกต้อง นี่คือจุดที่ผู้ให้บริการ DPI จับเราได้ ทำลายการเชื่อมต่อของเรา ในเวลาเดียวกัน เราไม่ได้รับต้นขั้วจากผู้ให้บริการ และเราเห็นข้อผิดพลาดมาตรฐานของเบราว์เซอร์ราวกับว่าไซต์ถูกปิดใช้งานหรือใช้งานไม่ได้:

ตอนนี้เรามาเปิดใช้งานกลไก eSNI ในเบราว์เซอร์ตามที่เขียนไว้ในคำแนะนำสำหรับ Firefox :
ในการทำเช่นนี้เราจะเปิดหน้าการกำหนดค่า Firefox about: config และเปิดใช้งานการตั้งค่าต่อไปนี้:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

หลังจากนี้ เราจะตรวจสอบว่าการตั้งค่าทำงานอย่างถูกต้องบนเว็บไซต์ cloudflare ลิงค์ และลองใช้เคล็ดลับกับเครื่องมือติดตาม torrent ของเราอีกครั้ง

เอาล่ะ เครื่องมือติดตามตัวโปรดของเราเปิดโดยไม่มี VPN หรือพร็อกซีเซิร์ฟเวอร์ ตอนนี้เรามาดูทราฟฟิกดัมพ์ใน wireshark เพื่อดูว่าเกิดอะไรขึ้น

คราวนี้แพ็คเกจ hello ของไคลเอ็นต์ ssl ไม่มีโดเมนปลายทางอย่างชัดเจน แต่มีฟิลด์ใหม่ปรากฏในแพ็คเกจแทน - encrypted_server_name - นี่คือที่ซึ่งค่าของ rutracker.nl มีอยู่และมีเพียงเซิร์ฟเวอร์ส่วนหน้าของ cloudflare เท่านั้นที่สามารถถอดรหัสนี้ได้ สนาม. และหากเป็นเช่นนั้น ผู้ให้บริการ DPI ก็ไม่มีทางเลือกอื่นนอกจากต้องล้างมือและอนุญาตให้มีการสัญจรดังกล่าว ไม่มีตัวเลือกอื่นที่มีการเข้ารหัส

ดังนั้นเราจึงดูว่าเทคโนโลยีทำงานอย่างไรในเบราว์เซอร์ ทีนี้ลองนำไปใช้กับสิ่งที่เฉพาะเจาะจงและน่าสนใจยิ่งขึ้น ก่อนอื่น เราจะสอนการใช้ curl แบบเดียวกันเพื่อใช้ eSNI เพื่อทำงานกับ TLS 1.3 และในเวลาเดียวกัน เราจะดูว่าโดเมนที่ใช้ eSNI ทำงานอย่างไร

การบังหน้าโดเมนด้วย eSNI

เนื่องจากความจริงที่ว่า curl ใช้ไลบรารี openssl มาตรฐานในการเชื่อมต่อผ่านโปรโตคอล https ก่อนอื่นเราจำเป็นต้องให้การสนับสนุน eSNI ที่นั่น ยังไม่มีการสนับสนุน eSNI ในสาขาหลักของ openssl ดังนั้นเราจึงจำเป็นต้องดาวน์โหลดสาขา openssl พิเศษ คอมไพล์และติดตั้ง

เราโคลนพื้นที่เก็บข้อมูลจาก GitHub และคอมไพล์ตามปกติ:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

ต่อไป เราจะโคลนพื้นที่เก็บข้อมูลด้วย curl และกำหนดค่าการคอมไพล์โดยใช้ไลบรารี openssl ที่คอมไพล์แล้วของเรา:

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

สิ่งสำคัญคือต้องระบุไดเรกทอรีทั้งหมดที่มี openssl อย่างถูกต้อง (ในกรณีของเรา นี่คือ /opt/openssl/) และตรวจสอบให้แน่ใจว่ากระบวนการกำหนดค่าดำเนินไปโดยไม่มีข้อผิดพลาด

หากการกำหนดค่าสำเร็จเราจะเห็นบรรทัด:

คำเตือน: เปิดใช้งาน esni ESNI แล้ว แต่ทำเครื่องหมายว่าเป็นแบบทดลอง ใช้ด้วยความระมัดระวัง!

$ make

หลังจากสร้างแพ็คเกจสำเร็จแล้ว เราจะใช้ไฟล์ bash พิเศษจาก openssl เพื่อกำหนดค่าและเรียกใช้ curl มาคัดลอกไปยังไดเร็กทอรีด้วย curl เพื่อความสะดวก:

cp /opt/openssl/esnistuff/curl-esni 

และทำการทดสอบคำขอ https ไปยังเซิร์ฟเวอร์ cloudflare ในขณะเดียวกันก็บันทึกแพ็กเก็ต DNS และ TLS ใน Wireshark ไปพร้อมๆ กัน

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

ในการตอบกลับของเซิร์ฟเวอร์ นอกเหนือจากข้อมูลการดีบักจำนวนมากจาก openssl และ curl แล้ว เราจะได้รับการตอบสนอง HTTP พร้อมโค้ด 301 จาก cloudflare

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

ซึ่งบ่งชี้ว่าคำขอของเราถูกส่งไปยังเซิร์ฟเวอร์ปลายทางสำเร็จแล้ว ได้ยินและประมวลผลแล้ว

ตอนนี้เรามาดูปริมาณการรับส่งข้อมูลใน wireshark เช่น สิ่งที่ผู้ให้บริการ DPI เห็นในกรณีนี้

จะเห็นได้ว่าในตอนแรก curl เปลี่ยนเป็นเซิร์ฟเวอร์ DNS สำหรับคีย์ eSNI สาธารณะสำหรับเซิร์ฟเวอร์ cloudflare - คำขอ TXT DNS ไปที่ _esni.cloudflare.com (แพ็คเกจหมายเลข 13) จากนั้น เมื่อใช้ไลบรารี openssl ทำให้ curl ส่งคำขอ TLS 1.3 ไปยังเซิร์ฟเวอร์ cloudflare ซึ่งมีการเข้ารหัสฟิลด์ SNI ด้วยคีย์สาธารณะที่ได้รับในขั้นตอนก่อนหน้า (แพ็กเก็ต #22) แต่นอกเหนือจากฟิลด์ eSNI แล้ว แพ็กเก็ต SSL-hello ยังรวมฟิลด์ที่มี SNI แบบเปิดตามปกติซึ่งเราสามารถระบุในลำดับใดก็ได้ (ในกรณีนี้ - www.hello-rkn.ru).

ฟิลด์ SNI แบบเปิดนี้ไม่ได้นำมาพิจารณาแต่อย่างใดเมื่อประมวลผลโดยเซิร์ฟเวอร์ cloudflare และทำหน้าที่เป็นมาสก์สำหรับ DPI ของผู้ให้บริการเท่านั้น เซิร์ฟเวอร์ cloudflare ได้รับแพ็กเก็ต ssl-hello ของเรา ถอดรหัส eSNI แยก SNI ดั้งเดิมจากที่นั่น และประมวลผลราวกับว่าไม่มีอะไรเกิดขึ้น (เมื่อพัฒนา eSNI มันทำทุกอย่างตรงตามที่วางแผนไว้)

สิ่งเดียวที่สามารถตรวจจับได้ในกรณีนี้จากมุมมอง DPI คือคำขอ DNS หลักที่ส่งไปยัง _esni.cloudflare.com แต่เราได้เปิดคำขอ DNS เพียงเพื่อแสดงวิธีการทำงานของกลไกนี้จากภายในเท่านั้น

เพื่อดึงพรมออกจากภายใต้ DPI ในที่สุด เราใช้กลไก DNS-over-HTTPS ที่กล่าวถึงแล้ว คำอธิบายเล็กๆ น้อยๆ - DOH เป็นโปรโตคอลที่ช่วยให้คุณสามารถป้องกันการโจมตีแบบแทรกกลางโดยการส่งคำขอ DNS ผ่าน HTTPS

มาดำเนินการตามคำขออีกครั้ง แต่คราวนี้เราจะได้รับคีย์ eSNI สาธารณะผ่านโปรโตคอล https ไม่ใช่ DNS:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

คำขอการถ่ายโอนข้อมูลการรับส่งข้อมูลจะแสดงในภาพหน้าจอด้านล่าง:

จะเห็นได้ว่า curl เข้าถึงเซิร์ฟเวอร์ mozilla.cloudflare-dns.com ก่อนผ่านโปรโตคอล DoH (การเชื่อมต่อ https ไปยังเซิร์ฟเวอร์ 104.16.249.249) เพื่อรับค่าของคีย์สาธารณะสำหรับการเข้ารหัส SNI จากนั้นไปยังปลายทาง เซิร์ฟเวอร์ซ่อนอยู่หลังโดเมน www.hello-rkn.ru.

นอกจาก mozilla.cloudflare-dns.com ตัวแก้ไข DoH ข้างต้นแล้ว เรายังใช้บริการ DoH ยอดนิยมอื่นๆ ได้ เช่น จากบริษัทชั่วร้ายชื่อดัง
มาเรียกใช้แบบสอบถามต่อไปนี้:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

และเราก็ได้คำตอบ:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

ในกรณีนี้ เราหันไปใช้เซิร์ฟเวอร์ rutracker.nl ที่ถูกบล็อกโดยใช้ DoH Resolver dns.google (ไม่มีการพิมพ์ผิดที่นี่ ตอนนี้บริษัทที่มีชื่อเสียงมีโดเมนระดับแรกเป็นของตัวเอง) และครอบคลุมตัวเราเองด้วยโดเมนอื่นซึ่งเคร่งครัด ห้ามไม่ให้ DPI ทั้งหมดปิดกั้นภายใต้ความเจ็บปวดแห่งความตาย จากคำตอบที่ได้รับ คุณสามารถเข้าใจได้ว่าคำขอของเราได้รับการประมวลผลสำเร็จแล้ว

เพื่อเป็นการตรวจสอบเพิ่มเติมว่า DPI ของผู้ให้บริการตอบสนองต่อ SNI แบบเปิดซึ่งเราส่งเป็นการปกปิด เราสามารถส่งคำขอไปยัง rutracker.nl ภายใต้หน้ากากของทรัพยากรต้องห้ามอื่น ๆ เช่น เครื่องมือติดตาม torrent ที่ "ดี" อื่น:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

เราจะไม่ได้รับการตอบกลับจากเซิร์ฟเวอร์ เนื่องจาก... คำขอของเราจะถูกบล็อกโดยระบบ DPI

บทสรุปสั้นๆ ของภาคแรก

ดังนั้นเราจึงสามารถสาธิตการทำงานของ eSNI โดยใช้ openssl และ curl และทดสอบการทำงานของโดเมนส่วนหน้าตาม eSNI ในทำนองเดียวกัน เราสามารถปรับเปลี่ยนเครื่องมือที่เราชื่นชอบซึ่งใช้ไลบรารี openssl เพื่อทำงาน "ภายใต้หน้ากาก" ของโดเมนอื่นๆ ได้ รายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้ในบทความถัดไปของเรา

ที่มา: will.com