สร้างระบบดักฟังเว็บเข้ารหัส (เช่น เฟซบุ๊ก) ที่บ้านด้วย mitmproxy

หมายเหตุ บทความนี้ไม่เกี่ยวกับข่าว “กระทรวงไอซีทีพยายามตรวจสอบและปิดกั้นเว็บเข้ารหัส ทดสอบที่เกตเวย์” แต่อย่างใด

เว็บและบริการคอมพิวเตอร์ยุคใหม่ส่วนมากมักเข้ารหัสอย่างแน่นหนาขึ้นเรื่อยๆ ในช่วงเวลาไม่กี่ปีที่ผ่านมา กระบวนการเข้ารหัสเหล่านี้คุ้มครองความเป็นส่วนตัวและความปลอดภัยของผู้ใช้ได้เป็นอย่างดี แต่แน่นอน หากวันดีเราเป็นเจ้าของบ้านที่ควบคุมเกตเวย์อินเทอร์เน็ต “ที่บ้าน” ได้โดยไม่มีการตรวจสอบ ไม่มีการถ่วงดุล สามารถทำอะไรได้ตามใจชอบ เราอาจจะเริ่มสงสัยว่าจริงๆ แล้วเราอยากส่องข้อความที่ทุกคนส่งเข้าออกจากบ้านของเราแม้จะเข้ารหัสได้หรือไม่

โครงสร้างความปลอดภัยอินเทอร์เน็ตสร้างขึ้นมาด้วยข้อจำกัดหลายอย่าง โดยเฉพาะแนวคิดระบบไร้ศูนย์กลาง ทำให้ระบบการยืนยันตัวตนเพื่อเข้ารหัส ที่โดยทั่วไปเราเห็นในรูปแบบการเชื่อมต่อ HTTPS (จริงๆ มีการเข้ารหัสที่ไม่ใช่ HTTPS อีกมากมาย แต่คนทั่วไปมักไม่เห็น)

การส่งข้อมูลในอินเทอร์เน็ตมีคุณสมบัติสำคัญเทียบกับระบบเครือข่ายคอมพิวเตอร์ในยุคก่อนอินเทอร์เน็ต คือ ข้อมูลการเชื่อมต่อจำนวนมากแชร์เส้นทางระหว่างกัน ทำให้คนดูแลสายเชื่อมต่อข้อมูลอาจจะเห็นข้อมูลการเชื่อมต่อของคนนับล้านคน จุดเชื่อมต่อเหล่านี้ทำหน้าที่เหมือนไปรษณีย์ในแต่ละประเทศ ที่เมื่อเห็นจดหมายมายังที่ทำการไปรษณีย์แล้ว จำเป็นต้องอ่านข้อมูลบางส่วน เพื่อจะรู้ว่าต้องส่งข้อมูลนี้ไปที่ไหนต่อ เช่น โปสการ์ดไปต่างประเทศ ไปรษณีย์ไทยก็จำเป็นต้องอ่านชื่อประเทศปลายทางเพื่อส่งโปสการ์ดไปยังไปรษณีย์ของประเทศปลายทางได้ถูกต้อง แต่หากไม่มีการป้องกันการอ่านอื่น การเข้าไปอ่านเนื้อหาทั้งที่ไม่จำเป็นก็ไม่ใช่เรื่องยากอะไร แต่หากข้อความมีการเข้ารหัสไว้ แม้จะเห็นข้อความก็ไม่สามารถอ่านเข้าใจได้

กระบวนการเข้ารหัสเว็บแยกเป็นสองส่วนคือ การยืนยันตัวตนว่าปลายทางที่เรากำลังสื่อสารอยู่ด้วยนั้นเป็นคนที่เราต้องการสื่อสารด้วยจริงหรือไม่ เมื่อยืนยันได้แล้วจึงสร้างกุญแจเข้ารหัสแลกกันไว้สองฝ่ายเพื่อเข้ารหัสการสื่อสารต่อไป กระบวนการดักฟังเว็บเข้ารหัสมีแนวคิดสำคัญคือ ถ้าเราไปคั่นกลางและหลอกว่าทั้งสองกำลังเชื่อมต่อกันโดยตรง และแลกกุญแจเข้ารหัสกับเครื่องที่คั่นกลาง เครื่องที่คั่นกลางก็จะสามารถอ่านข้อความได้ทั้งหมด การโจมตีแบบนี้เรียกว่า man-in-the-middle attrack หรือ MITM ที่เป็นที่มาของชื่อ mitmproxy ที่ใช้ในบทความนี้

ดักฟังเว็บเข้ารหัส

mitmproxy สามารถดักการเชื่อมต่อ HTTP โดยสร้างใบรับรองปลอมขึ้นทุกครั้งที่มีการเชื่อมต่อ ไม่ว่าจะเชื่อมต่อไปหาเซิร์ฟเวอร์อะไร mitmproxy จะสร้างใบรับรองใหม่ อ้างว่าตัวเองเป็นเซิร์ฟเวอร์นั้นๆ เสมอ

การทดสอบ เราติดตั้ง mitmproxy ไว้ในเกตเวย์ที่เป็นลินุกซ์ ในกรณีที่เกตเวย์เป็นเราเตอร์เฉพาะอาจจะต้องคอนฟิกแบบอื่นๆ แต่จะอยู่นอกเหนือขอบเขตบทความนี้

การรันคำสั่ง mitmproxy -T จะทำให้ mitmproxy รอรับการเชื่อมต่ออยู่ในพอร์ต 8080 ทันที ในกรณีที่เราต้องการให้ mitmproxy ดักจับการเชื่อมต่อเว็บแบบเข้ารหัส เราต้องส่งการเชื่อมต่อจากพอร์ต 443 (HTTPS) เข้าพอยังพอร์ต 8080 ของ mitmproxy

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j REDIRECT –to-port 8080

เมื่อเราอยากอ่านแล้วไม่เชื่อคำเตือนของเบราว์เซอร์จะเกิดอะไร (ภาพบน) คำเตือนเมื่อการเชื่อมต่อถูกคั่นกลาง (ภาพล่าง) เมื่อกดยืนยันเชื่อมต่อเบราว์เซอร์ยังคงเตือนต่อไป

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

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

ความเนียนคือความท้าทาย

กระบวนการทำให้ “เนียน” เป็นหัวข้อใหญ่ในการดักฟังเว็บเข้ารหัส ที่ออกแบบมาเพื่อป้องกันการดักฟัง เว็บทั้งโลกที่เข้ารหัส ล้วนถูกตรวจสอบว่าคนที่กำลังแสดงตัวว่าเป็นเจ้าของเว็บนั้นเป็นตัวจริงหรือไม่ หน่วยงานนี้เรียกว่า Certification Authority หรือ CA ทั่วโลกมีมากมายนับไม่ถ้วน แต่ที่เบราว์เซอร์และระบบปฎิบัติการต่างๆ ให้ความเชื่อถือยอมรับว่ามีกระบวนการตรวจสอบที่ดีนั้น มีการกำหนดมาตรฐานความน่าเชื่อถือเอาไว้โดยกลุ่มร่วมระหว่างผู้ผลิตซอฟต์แวร์และหน่วยงานรับรองเว็บเอง โดยรวมทำข้อตกลงกันในชื่อหน่วยงานว่า CA Browser Forum นอกจากนี้แต่ละเบราว์เซอร์ยังกำหนดข้อตกลงเพิ่มเติมของตัวเองได้ เช่น ตัวอย่างข้อกำหนดของ Mozilla

องค์กรสามารถบังคับให้เครื่องในองค์กรเชื่อใบรับรองของเซิร์ฟเวอร์ที่คั่นกลางได้

mitmproxy เองรองรับการสร้างใบรับรองปลอมด้วย CA ของหน่วยงาน โดยสามารถสร้างใบรับรองที่รับรองโดย CA ที่ระบุได้อัตโนมัติ กระบวนการปกติแล้วจำเป็นต้องเพิ่มใบรับรองของ CA หน่วยงานนี้ให้เบราว์เซอร์ “เชื่อใจ” โดยตรง หากเป็นเครื่องในองค์กร ที่ถูกควบคุมจากฝ่ายไอที เช่น เครื่องที่อยู่ใต้โดเมน องค์กรสามารถเพิ่ม CA ของตัวเองเข้าไปให้กับทุกเครื่องได้ทันที และซอฟต์แวร์ เช่น mitmproxy ก็จะสามารถดักฟังเว็บได้โดยที่เบราว์เซอร์ไม่ขึ้นหน้าจอเตือนใดๆ กระบวนการแบบนี้ใช้กันในองค์กรขนาดใหญ่ที่ต้องการควบคุมการส่งข้อมูลออกนอกองค์กรจากเครื่องคอมพิวเตอร์ขององค์กรเอง

การบังคับบางครั้งอาจจะเป็นกระบวนการง่ายๆ คือเปิดไฟล์ CA ให้ดาวน์โหลดไปติดตั้งเอง พร้อมบอกกระบวนการติดตั้งมาให้ ควรตระหนักว่าการติดตั้งไฟล์ CA ลงเครื่องหมายถึงผู้ที่ออก CA นั้นให้เราอาจจะดักฟังเว็บใดๆ ก็ได้ตามต้องการ แม้จะเป็นเว็บเข้ารหัส

คำถามสำคัญ คือ ถ้าไม่ใช่เรื่องขององค์กรที่เข้าไปแก้ไขได้โดยตรง จะสามารถดักฟังการเข้ารหัสให้เนียนได้หรือไม่ คำตอบคือ ได้ ถ้าเราสามารถหาใบรับรองที่ “เหมือนจริง” ได้ กรณีเคยเกิดขึ้นในอิหร่าน เมื่อมีผู้พบว่ามีใบรับรองที่รับรองโดเมน google.com แต่ทางกูเกิลไม่ได้ขอ สุดท้ายพบว่าเป็นใบรับรองที่แฮกมาจาก CA ชื่อ Diginotar กระบวนการดักฟังนั้นเนียนอย่างสมบูรณ์ หากไม่ใช่เพราะว่าเบราว์เซอร์ Chrome ล็อกไว้ว่าเมื่อเป็นเว็บของกูเกิลต้องใช้ใบรับรองเฉพาะที่ระบุไว้เท่านั้น ใบรับรองอื่นๆ แม้ได้รับการรับรองมาถูกต้อง Chrome ก็จะเตือนอยู่ดี

ใบรับรองถูกต้องก็ไม่พอ

กระบวนการดักฟังการเข้ารหัสโดยไม่สามารถสังเกตได้ยังมีอีกรูปแบบหนึ่ง คือ การควบคุม CA จริงที่ไม่ได้เป็น CA สำหรับภายในองค์กรอย่างเดียว เนื่องจากระบบ CA นั้นรองรับการ “ส่งต่อสิทธิ” (delegate) ความน่าเชื่อถือไปให้หน่วยงานอื่นๆ ได้ root CA ที่ได้รับความเชื่อถือจากเบราว์เซอร์หลัก อาจจะส่งต่อสิทธิ์ให้กับหน่วยงานอื่นๆ อีกนับร้อย CA ที่ได้รับสิทธิแบบส่งต่อมาและ root CA รวมทั้งหมดที่ได้รับความเชื่อถือจากเบราว์เซอร์หลักๆ มีนับร้อยนับพันรายการ CA หลายแห่งเป็นหน่วยงานรัฐบาล ที่เคยมีประเด็นเช่น Etisalat หน่วยงานที่ได้รับสิทธิความน่าเชื่อถือต่อมาจาก CA ของบริษัท Verizon ตัว Etisalat เป็นหน่วยงานที่อยู่ใต้กำกับของรัฐบาลสหรัฐอาหรับเอมิเรตส์ EFF เคยเรียกร้องให้ Verizon ถอนสิทธิของ Etisalat เสียเพราะบริษัทเป็นผู้ให้บริการโทรศัพท์มือถือด้วย และเคยส่งอัพเดตปลอมให้กับผู้ใช้ Blackberry ในเครือข่ายนับแสนคน อย่างไรก็ดี Verizon ยังไม่ได้ถอน CA ของ Etisalat และใบรับรองที่ออกโดย Etisalat ก็ยังใช้งานได้ทั่วโลก

จนทุกวันนี้ไม่มีใครรู้แน่ชัดว่า CA ที่ได้รับสิทธิต่อมาจาก root CA มีรวมทั้งหมดจำนวนเท่าใดและมีใครบ้าง เพราะไม่มีข้อกำหนดว่า root CA ต้องประกาศ CA ที่ส่งต่อสิทธิไปให้

การได้มาซึ่งใบรับรองปลอมที่เบราว์เซอร์เชื่อถือเป็นกระบวนการที่ค่าใช้จ่ายสูงในแทบทุกทาง ไม่ว่าจะเป็นการแฮกจาก CA ซึ่งเป็นอาชญากรรม และต้องเตรียมการเป็นเวลานาน หรือการสร้าง CA แล้วซื้อสิทธิที่ได้รับส่งต่อมา กระบวนการนี้ดูจะมีประสิทธิภาพดีหากมีความต้องการที่จะดักฟังเว็บทั่วๆ ไป

กระบวนการต่อสู้กับการดักฟัง

แต่ความตระหนกว่าจะมี CA ออกใบรับรองให้กับผู้อื่นที่ไม่ใช่เจ้าของโดเมนเป็นประเด็นสำคัญทั่วโลกมาโดยเสมอ ทุกวันนี้มีการเรียกร้องให้ CA ทุกรายเปิดรายการใบรับรองที่ได้รับรองให้ไปเพื่อให้เจ้าของโดเมนสามารถตรวจสอบได้ว่ามีการออกใบรับรองอย่างไม่ถูกต้องหรือไม่ ในอีกทางหนึ่งเบราว์เซอร์เองเริ่มรองรับการ “ล็อก” CA ให้กับบางเว็บที่มีความนิยมสูง เช่นเดียวกับที่ Chrome ล็อกจนกระทั่งพบว่า DigiNotar ออกใบรับรองโดยไม่ได้รับอนุญาต ทุกวันนี้กระบวนการนี้เปิดให้เว็บขนาดใหญ่สามารถเจรจากับเบราว์เซอร์เพื่อขอให้ล็อกว่าใบรับรองของเว็บตัวเองจะออกโดย CA รายใดได้บ้าง ตัวอย่างเช่นใน Chrome 40 เป็นต้นไป เฟซบุ๊กจะออกใบรับรองได้จาก Symanctec, Digicert, และ CA สำรองของเฟซบุ๊กเองเท่านั้น โดเมนดังๆ ที่มีคนใช้จำนวนมากล้วนเจรจากับเบราว์เซอร์ในรูปแบบเดียวกับ เช่น ทวิตเตอร์, กูเกิล, Dropbox, torproject.org, หรือเว็บสำรองข้อมูลอย่าง SpiderOak สำหรับไฟร์ฟอกซ์เองก็มีนโยบายว่าเว็บใดที่ล็อก CA กับ Chrome แล้วทางไฟร์ฟอกซ์จะล็อกในแบบเดียวกัน

กระบวนการเจรจาระหว่างเว็บกับเบราว์เซอร์อาจจะใช้เวลานาน กูเกิลเสนอมาตรฐานใหม่ “Public Key Pinning Extension for HTTP” หรือ HPKP มาตั้งแต่ปี 2011 มีแนวโน้มว่าจะเป็นมาตรฐานเว็บต่อไป มาตรฐานนี้จะเปิดให้เว็บสามารถส่งข้อความแจ้งเบราว์เซอร์ได้ว่าต่อจากนี้จะมีใบรับรองใดถูกต้องบ้าง และหากพบใบรับรองที่ไม่อยู่ในรายการ สามารถเตือนให้เบราว์เซอร์แจ้งเตือนกลับไปยังเซิร์ฟเวอร์ได้ว่ามีใบรับรองน่าสงสัย ทุกวันนี้ยังคงมีเพียง Chrome (38 ขึ้นไป) และ Firefox (35 ขึ้นไป) เท่านั้นที่รองรับมาตรฐานนี้

ดักฟังกลายเป็นบล็อคเว็บ

กระบวนการดักฟังให้ผู้ใช้ไม่รู้ตัว เป็นเรื่องใหญ่ที่ต้องลงทุนสูงและมีโอกาสพลาดมากมายในช่วงหลังก แต่หากมีองค์กรที่ไม่สนใจอะไรและอยาก “ฟัง” เพียงอย่างเดียวโดยไม่สนใจว่าผู้ใช้จะรู้ตัวหรือไม่ก็ยังคงสามารถทำได้โดยลงทันไม่มากมายอะไรนัก เช่น mitmproxy ที่ยกตัวอย่างไปสามารถติดตั้งในองค์กรขนาดเล็กได้โดยง่าย

แต่มีข้อเสนอเพิ่มเติมในวงการความปลอดภัย คือ HTTP Strict Transport Security ที่เสนอโดยกูเกิล ทำให้เว็บสามารถประกาศตัวเองว่าต้องเข้ารหัสเท่านั้น ทำให้เบราว์เซอร์จะไม่พยายามเข้าเว็บนี้แบบไม่เข้ารหัสอีกเลย แม้ผู้ใช้จะพิมพ์ URL แบบไม่เข้ารหัสก็ตาม (rfc6797 ข้อ 12.1) เว็บที่ล็อก CA มักจะประกาศ HSTS อยู่เสมอ ทุกวันนี้การปลอมใบรับรองเฟซบุ๊กจึงเป็นการบล็อคเว็บไปในตัว เช่นในภาพ Chrome จะไม่แสดงปุ่ม Proceed เพื่อเข้าเว็บหากใบรับรองผิดพลาด

Get latest news form Blognone


Follow @twitterapi

สำนักข่าวWiFi Phitsanulok

ขอบคุณที่มาของข่าวโดยblognone.com ข่าวไอที
เวลาโพส2015-02-05 03:26:15

สร้างระบบดักฟังเว็บเข้ารหัส (เช่น เฟซบุ๊ก) ที่บ้านด้วย mitmproxy
https://www.blognone.com/sites/default/files/imagecache/news-thumbnail/category_pictures/ssl100.png

หมายเหตุ บทความนี้ไม่เกี่ยวกับข่าว “กระทรวงไอซีทีพยายามตรวจสอบและปิดกั้นเว็บเข้ารหัส ทดสอบที่เกตเวย์” แต่อย่างใด

เว็บและบริการคอมพิวเตอร์ยุคใหม่ส่วนมากมักเข้ารหัสอย่างแน่นหนาขึ้นเรื่อยๆ ในช่วงเวลาไม่กี่ปีที่ผ่านมา กระบวนการเข้ารหัสเหล่านี้คุ้มครองความเป็นส่วนตัวและความปลอดภัยของผู้ใช้ได้เป็นอย่างดี แต่แน่นอน หากวันดีเราเป็นเจ้าของบ้านที่ควบคุมเกตเวย์อินเทอร์เน็ต “ที่บ้าน” ได้โดยไม่มีการตรวจสอบ ไม่มีการถ่วงดุล สามารถทำอะไรได้ตามใจชอบ เราอาจจะเริ่มสงสัยว่าจริงๆ แล้วเราอยากส่องข้อความที่ทุกคนส่งเข้าออกจากบ้านของเราแม้จะเข้ารหัสได้หรือไม่

โครงสร้างความปลอดภัยอินเทอร์เน็ตสร้างขึ้นมาด้วยข้อจำกัดหลายอย่าง โดยเฉพาะแนวคิดระบบไร้ศูนย์กลาง ทำให้ระบบการยืนยันตัวตนเพื่อเข้ารหัส ที่โดยทั่วไปเราเห็นในรูปแบบการเชื่อมต่อ HTTPS (จริงๆ มีการเข้ารหัสที่ไม่ใช่ HTTPS อีกมากมาย แต่คนทั่วไปมักไม่เห็น)

การส่งข้อมูลในอินเทอร์เน็ตมีคุณสมบัติสำคัญเทียบกับระบบเครือข่ายคอมพิวเตอร์ในยุคก่อนอินเทอร์เน็ต คือ ข้อมูลการเชื่อมต่อจำนวนมากแชร์เส้นทางระหว่างกัน ทำให้คนดูแลสายเชื่อมต่อข้อมูลอาจจะเห็นข้อมูลการเชื่อมต่อของคนนับล้านคน จุดเชื่อมต่อเหล่านี้ทำหน้าที่เหมือนไปรษณีย์ในแต่ละประเทศ ที่เมื่อเห็นจดหมายมายังที่ทำการไปรษณีย์แล้ว จำเป็นต้องอ่านข้อมูลบางส่วน เพื่อจะรู้ว่าต้องส่งข้อมูลนี้ไปที่ไหนต่อ เช่น โปสการ์ดไปต่างประเทศ ไปรษณีย์ไทยก็จำเป็นต้องอ่านชื่อประเทศปลายทางเพื่อส่งโปสการ์ดไปยังไปรษณีย์ของประเทศปลายทางได้ถูกต้อง แต่หากไม่มีการป้องกันการอ่านอื่น การเข้าไปอ่านเนื้อหาทั้งที่ไม่จำเป็นก็ไม่ใช่เรื่องยากอะไร แต่หากข้อความมีการเข้ารหัสไว้ แม้จะเห็นข้อความก็ไม่สามารถอ่านเข้าใจได้

กระบวนการเข้ารหัสเว็บแยกเป็นสองส่วนคือ การยืนยันตัวตนว่าปลายทางที่เรากำลังสื่อสารอยู่ด้วยนั้นเป็นคนที่เราต้องการสื่อสารด้วยจริงหรือไม่ เมื่อยืนยันได้แล้วจึงสร้างกุญแจเข้ารหัสแลกกันไว้สองฝ่ายเพื่อเข้ารหัสการสื่อสารต่อไป กระบวนการดักฟังเว็บเข้ารหัสมีแนวคิดสำคัญคือ ถ้าเราไปคั่นกลางและหลอกว่าทั้งสองกำลังเชื่อมต่อกันโดยตรง และแลกกุญแจเข้ารหัสกับเครื่องที่คั่นกลาง เครื่องที่คั่นกลางก็จะสามารถอ่านข้อความได้ทั้งหมด การโจมตีแบบนี้เรียกว่า man-in-the-middle attrack หรือ MITM ที่เป็นที่มาของชื่อ mitmproxy ที่ใช้ในบทความนี้

ดักฟังเว็บเข้ารหัส

mitmproxy สามารถดักการเชื่อมต่อ HTTP โดยสร้างใบรับรองปลอมขึ้นทุกครั้งที่มีการเชื่อมต่อ ไม่ว่าจะเชื่อมต่อไปหาเซิร์ฟเวอร์อะไร mitmproxy จะสร้างใบรับรองใหม่ อ้างว่าตัวเองเป็นเซิร์ฟเวอร์นั้นๆ เสมอ

การทดสอบ เราติดตั้ง mitmproxy ไว้ในเกตเวย์ที่เป็นลินุกซ์ ในกรณีที่เกตเวย์เป็นเราเตอร์เฉพาะอาจจะต้องคอนฟิกแบบอื่นๆ แต่จะอยู่นอกเหนือขอบเขตบทความนี้

การรันคำสั่ง mitmproxy -T จะทำให้ mitmproxy รอรับการเชื่อมต่ออยู่ในพอร์ต 8080 ทันที ในกรณีที่เราต้องการให้ mitmproxy ดักจับการเชื่อมต่อเว็บแบบเข้ารหัส เราต้องส่งการเชื่อมต่อจากพอร์ต 443 (HTTPS) เข้าพอยังพอร์ต 8080 ของ mitmproxy

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j REDIRECT –to-port 8080

เมื่อเราอยากอ่านแล้วไม่เชื่อคำเตือนของเบราว์เซอร์จะเกิดอะไร (ภาพบน) คำเตือนเมื่อการเชื่อมต่อถูกคั่นกลาง (ภาพล่าง) เมื่อกดยืนยันเชื่อมต่อเบราว์เซอร์ยังคงเตือนต่อไป

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

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

ความเนียนคือความท้าทาย

กระบวนการทำให้ “เนียน” เป็นหัวข้อใหญ่ในการดักฟังเว็บเข้ารหัส ที่ออกแบบมาเพื่อป้องกันการดักฟัง เว็บทั้งโลกที่เข้ารหัส ล้วนถูกตรวจสอบว่าคนที่กำลังแสดงตัวว่าเป็นเจ้าของเว็บนั้นเป็นตัวจริงหรือไม่ หน่วยงานนี้เรียกว่า Certification Authority หรือ CA ทั่วโลกมีมากมายนับไม่ถ้วน แต่ที่เบราว์เซอร์และระบบปฎิบัติการต่างๆ ให้ความเชื่อถือยอมรับว่ามีกระบวนการตรวจสอบที่ดีนั้น มีการกำหนดมาตรฐานความน่าเชื่อถือเอาไว้โดยกลุ่มร่วมระหว่างผู้ผลิตซอฟต์แวร์และหน่วยงานรับรองเว็บเอง โดยรวมทำข้อตกลงกันในชื่อหน่วยงานว่า CA Browser Forum นอกจากนี้แต่ละเบราว์เซอร์ยังกำหนดข้อตกลงเพิ่มเติมของตัวเองได้ เช่น ตัวอย่างข้อกำหนดของ Mozilla

องค์กรสามารถบังคับให้เครื่องในองค์กรเชื่อใบรับรองของเซิร์ฟเวอร์ที่คั่นกลางได้

mitmproxy เองรองรับการสร้างใบรับรองปลอมด้วย CA ของหน่วยงาน โดยสามารถสร้างใบรับรองที่รับรองโดย CA ที่ระบุได้อัตโนมัติ กระบวนการปกติแล้วจำเป็นต้องเพิ่มใบรับรองของ CA หน่วยงานนี้ให้เบราว์เซอร์ “เชื่อใจ” โดยตรง หากเป็นเครื่องในองค์กร ที่ถูกควบคุมจากฝ่ายไอที เช่น เครื่องที่อยู่ใต้โดเมน องค์กรสามารถเพิ่ม CA ของตัวเองเข้าไปให้กับทุกเครื่องได้ทันที และซอฟต์แวร์ เช่น mitmproxy ก็จะสามารถดักฟังเว็บได้โดยที่เบราว์เซอร์ไม่ขึ้นหน้าจอเตือนใดๆ กระบวนการแบบนี้ใช้กันในองค์กรขนาดใหญ่ที่ต้องการควบคุมการส่งข้อมูลออกนอกองค์กรจากเครื่องคอมพิวเตอร์ขององค์กรเอง

การบังคับบางครั้งอาจจะเป็นกระบวนการง่ายๆ คือเปิดไฟล์ CA ให้ดาวน์โหลดไปติดตั้งเอง พร้อมบอกกระบวนการติดตั้งมาให้ ควรตระหนักว่าการติดตั้งไฟล์ CA ลงเครื่องหมายถึงผู้ที่ออก CA นั้นให้เราอาจจะดักฟังเว็บใดๆ ก็ได้ตามต้องการ แม้จะเป็นเว็บเข้ารหัส

คำถามสำคัญ คือ ถ้าไม่ใช่เรื่องขององค์กรที่เข้าไปแก้ไขได้โดยตรง จะสามารถดักฟังการเข้ารหัสให้เนียนได้หรือไม่ คำตอบคือ ได้ ถ้าเราสามารถหาใบรับรองที่ “เหมือนจริง” ได้ กรณีเคยเกิดขึ้นในอิหร่าน เมื่อมีผู้พบว่ามีใบรับรองที่รับรองโดเมน google.com แต่ทางกูเกิลไม่ได้ขอ สุดท้ายพบว่าเป็นใบรับรองที่แฮกมาจาก CA ชื่อ Diginotar กระบวนการดักฟังนั้นเนียนอย่างสมบูรณ์ หากไม่ใช่เพราะว่าเบราว์เซอร์ Chrome ล็อกไว้ว่าเมื่อเป็นเว็บของกูเกิลต้องใช้ใบรับรองเฉพาะที่ระบุไว้เท่านั้น ใบรับรองอื่นๆ แม้ได้รับการรับรองมาถูกต้อง Chrome ก็จะเตือนอยู่ดี

ใบรับรองถูกต้องก็ไม่พอ

กระบวนการดักฟังการเข้ารหัสโดยไม่สามารถสังเกตได้ยังมีอีกรูปแบบหนึ่ง คือ การควบคุม CA จริงที่ไม่ได้เป็น CA สำหรับภายในองค์กรอย่างเดียว เนื่องจากระบบ CA นั้นรองรับการ “ส่งต่อสิทธิ” (delegate) ความน่าเชื่อถือไปให้หน่วยงานอื่นๆ ได้ root CA ที่ได้รับความเชื่อถือจากเบราว์เซอร์หลัก อาจจะส่งต่อสิทธิ์ให้กับหน่วยงานอื่นๆ อีกนับร้อย CA ที่ได้รับสิทธิแบบส่งต่อมาและ root CA รวมทั้งหมดที่ได้รับความเชื่อถือจากเบราว์เซอร์หลักๆ มีนับร้อยนับพันรายการ CA หลายแห่งเป็นหน่วยงานรัฐบาล ที่เคยมีประเด็นเช่น Etisalat หน่วยงานที่ได้รับสิทธิความน่าเชื่อถือต่อมาจาก CA ของบริษัท Verizon ตัว Etisalat เป็นหน่วยงานที่อยู่ใต้กำกับของรัฐบาลสหรัฐอาหรับเอมิเรตส์ EFF เคยเรียกร้องให้ Verizon ถอนสิทธิของ Etisalat เสียเพราะบริษัทเป็นผู้ให้บริการโทรศัพท์มือถือด้วย และเคยส่งอัพเดตปลอมให้กับผู้ใช้ Blackberry ในเครือข่ายนับแสนคน อย่างไรก็ดี Verizon ยังไม่ได้ถอน CA ของ Etisalat และใบรับรองที่ออกโดย Etisalat ก็ยังใช้งานได้ทั่วโลก

จนทุกวันนี้ไม่มีใครรู้แน่ชัดว่า CA ที่ได้รับสิทธิต่อมาจาก root CA มีรวมทั้งหมดจำนวนเท่าใดและมีใครบ้าง เพราะไม่มีข้อกำหนดว่า root CA ต้องประกาศ CA ที่ส่งต่อสิทธิไปให้

การได้มาซึ่งใบรับรองปลอมที่เบราว์เซอร์เชื่อถือเป็นกระบวนการที่ค่าใช้จ่ายสูงในแทบทุกทาง ไม่ว่าจะเป็นการแฮกจาก CA ซึ่งเป็นอาชญากรรม และต้องเตรียมการเป็นเวลานาน หรือการสร้าง CA แล้วซื้อสิทธิที่ได้รับส่งต่อมา กระบวนการนี้ดูจะมีประสิทธิภาพดีหากมีความต้องการที่จะดักฟังเว็บทั่วๆ ไป

กระบวนการต่อสู้กับการดักฟัง

แต่ความตระหนกว่าจะมี CA ออกใบรับรองให้กับผู้อื่นที่ไม่ใช่เจ้าของโดเมนเป็นประเด็นสำคัญทั่วโลกมาโดยเสมอ ทุกวันนี้มีการเรียกร้องให้ CA ทุกรายเปิดรายการใบรับรองที่ได้รับรองให้ไปเพื่อให้เจ้าของโดเมนสามารถตรวจสอบได้ว่ามีการออกใบรับรองอย่างไม่ถูกต้องหรือไม่ ในอีกทางหนึ่งเบราว์เซอร์เองเริ่มรองรับการ “ล็อก” CA ให้กับบางเว็บที่มีความนิยมสูง เช่นเดียวกับที่ Chrome ล็อกจนกระทั่งพบว่า DigiNotar ออกใบรับรองโดยไม่ได้รับอนุญาต ทุกวันนี้กระบวนการนี้เปิดให้เว็บขนาดใหญ่สามารถเจรจากับเบราว์เซอร์เพื่อขอให้ล็อกว่าใบรับรองของเว็บตัวเองจะออกโดย CA รายใดได้บ้าง ตัวอย่างเช่นใน Chrome 40 เป็นต้นไป เฟซบุ๊กจะออกใบรับรองได้จาก Symanctec, Digicert, และ CA สำรองของเฟซบุ๊กเองเท่านั้น โดเมนดังๆ ที่มีคนใช้จำนวนมากล้วนเจรจากับเบราว์เซอร์ในรูปแบบเดียวกับ เช่น ทวิตเตอร์, กูเกิล, Dropbox, torproject.org, หรือเว็บสำรองข้อมูลอย่าง SpiderOak สำหรับไฟร์ฟอกซ์เองก็มีนโยบายว่าเว็บใดที่ล็อก CA กับ Chrome แล้วทางไฟร์ฟอกซ์จะล็อกในแบบเดียวกัน

กระบวนการเจรจาระหว่างเว็บกับเบราว์เซอร์อาจจะใช้เวลานาน กูเกิลเสนอมาตรฐานใหม่ “Public Key Pinning Extension for HTTP” หรือ HPKP มาตั้งแต่ปี 2011 มีแนวโน้มว่าจะเป็นมาตรฐานเว็บต่อไป มาตรฐานนี้จะเปิดให้เว็บสามารถส่งข้อความแจ้งเบราว์เซอร์ได้ว่าต่อจากนี้จะมีใบรับรองใดถูกต้องบ้าง และหากพบใบรับรองที่ไม่อยู่ในรายการ สามารถเตือนให้เบราว์เซอร์แจ้งเตือนกลับไปยังเซิร์ฟเวอร์ได้ว่ามีใบรับรองน่าสงสัย ทุกวันนี้ยังคงมีเพียง Chrome (38 ขึ้นไป) และ Firefox (35 ขึ้นไป) เท่านั้นที่รองรับมาตรฐานนี้

ดักฟังกลายเป็นบล็อคเว็บ

กระบวนการดักฟังให้ผู้ใช้ไม่รู้ตัว เป็นเรื่องใหญ่ที่ต้องลงทุนสูงและมีโอกาสพลาดมากมายในช่วงหลังก แต่หากมีองค์กรที่ไม่สนใจอะไรและอยาก “ฟัง” เพียงอย่างเดียวโดยไม่สนใจว่าผู้ใช้จะรู้ตัวหรือไม่ก็ยังคงสามารถทำได้โดยลงทันไม่มากมายอะไรนัก เช่น mitmproxy ที่ยกตัวอย่างไปสามารถติดตั้งในองค์กรขนาดเล็กได้โดยง่าย

แต่มีข้อเสนอเพิ่มเติมในวงการความปลอดภัย คือ HTTP Strict Transport Security ที่เสนอโดยกูเกิล ทำให้เว็บสามารถประกาศตัวเองว่าต้องเข้ารหัสเท่านั้น ทำให้เบราว์เซอร์จะไม่พยายามเข้าเว็บนี้แบบไม่เข้ารหัสอีกเลย แม้ผู้ใช้จะพิมพ์ URL แบบไม่เข้ารหัสก็ตาม (rfc6797 ข้อ 12.1) เว็บที่ล็อก CA มักจะประกาศ HSTS อยู่เสมอ ทุกวันนี้การปลอมใบรับรองเฟซบุ๊กจึงเป็นการบล็อคเว็บไปในตัว เช่นในภาพ Chrome จะไม่แสดงปุ่ม Proceed เพื่อเข้าเว็บหากใบรับรองผิดพลาด

Get latest news form Blognone


Follow @twitterapi

สำนักข่าวWiFi Phitsanulok

ขอบคุณที่มาของข่าวโดยblognone.com ข่าวไอที
เวลาโพส2015-02-05 03:26:15

หมายเหตุ บทความนี้ไม่เกี่ยวกับข่าว "กระทรวงไอซีทีพยายามตรวจสอบและปิดกั้นเว็บเข้ารหัส ทดสอบที่เกตเวย์" แต่อย่างใด

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

โครงสร้างความปลอดภัยอินเทอร์เน็ตสร้างขึ้นมาด้วยข้อจำกัดหลายอย่าง โดยเฉพาะแนวคิดระบบไร้ศูนย์กลาง ทำให้ระบบการยืนยันตัวตนเพื่อเข้ารหัส ที่โดยทั่วไปเราเห็นในรูปแบบการเชื่อมต่อ HTTPS (จริงๆ มีการเข้ารหัสที่ไม่ใช่ HTTPS อีกมากมาย แต่คนทั่วไปมักไม่เห็น)

การส่งข้อมูลในอินเทอร์เน็ตมีคุณสมบัติสำคัญเทียบกับระบบเครือข่ายคอมพิวเตอร์ในยุคก่อนอินเทอร์เน็ต คือ ข้อมูลการเชื่อมต่อจำนวนมากแชร์เส้นทางระหว่างกัน ทำให้คนดูแลสายเชื่อมต่อข้อมูลอาจจะเห็นข้อมูลการเชื่อมต่อของคนนับล้านคน จุดเชื่อมต่อเหล่านี้ทำหน้าที่เหมือนไปรษณีย์ในแต่ละประเทศ ที่เมื่อเห็นจดหมายมายังที่ทำการไปรษณีย์แล้ว จำเป็นต้องอ่านข้อมูลบางส่วน เพื่อจะรู้ว่าต้องส่งข้อมูลนี้ไปที่ไหนต่อ เช่น โปสการ์ดไปต่างประเทศ ไปรษณีย์ไทยก็จำเป็นต้องอ่านชื่อประเทศปลายทางเพื่อส่งโปสการ์ดไปยังไปรษณีย์ของประเทศปลายทางได้ถูกต้อง แต่หากไม่มีการป้องกันการอ่านอื่น การเข้าไปอ่านเนื้อหาทั้งที่ไม่จำเป็นก็ไม่ใช่เรื่องยากอะไร แต่หากข้อความมีการเข้ารหัสไว้ แม้จะเห็นข้อความก็ไม่สามารถอ่านเข้าใจได้

กระบวนการเข้ารหัสเว็บแยกเป็นสองส่วนคือ การยืนยันตัวตนว่าปลายทางที่เรากำลังสื่อสารอยู่ด้วยนั้นเป็นคนที่เราต้องการสื่อสารด้วยจริงหรือไม่ เมื่อยืนยันได้แล้วจึงสร้างกุญแจเข้ารหัสแลกกันไว้สองฝ่ายเพื่อเข้ารหัสการสื่อสารต่อไป กระบวนการดักฟังเว็บเข้ารหัสมีแนวคิดสำคัญคือ ถ้าเราไปคั่นกลางและหลอกว่าทั้งสองกำลังเชื่อมต่อกันโดยตรง และแลกกุญแจเข้ารหัสกับเครื่องที่คั่นกลาง เครื่องที่คั่นกลางก็จะสามารถอ่านข้อความได้ทั้งหมด การโจมตีแบบนี้เรียกว่า man-in-the-middle attrack หรือ MITM ที่เป็นที่มาของชื่อ mitmproxy ที่ใช้ในบทความนี้

ดักฟังเว็บเข้ารหัส

mitmproxy สามารถดักการเชื่อมต่อ HTTP โดยสร้างใบรับรองปลอมขึ้นทุกครั้งที่มีการเชื่อมต่อ ไม่ว่าจะเชื่อมต่อไปหาเซิร์ฟเวอร์อะไร mitmproxy จะสร้างใบรับรองใหม่ อ้างว่าตัวเองเป็นเซิร์ฟเวอร์นั้นๆ เสมอ

การทดสอบ เราติดตั้ง mitmproxy ไว้ในเกตเวย์ที่เป็นลินุกซ์ ในกรณีที่เกตเวย์เป็นเราเตอร์เฉพาะอาจจะต้องคอนฟิกแบบอื่นๆ แต่จะอยู่นอกเหนือขอบเขตบทความนี้

การรันคำสั่ง mitmproxy -T จะทำให้ mitmproxy รอรับการเชื่อมต่ออยู่ในพอร์ต 8080 ทันที ในกรณีที่เราต้องการให้ mitmproxy ดักจับการเชื่อมต่อเว็บแบบเข้ารหัส เราต้องส่งการเชื่อมต่อจากพอร์ต 443 (HTTPS) เข้าพอยังพอร์ต 8080 ของ mitmproxy

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

เมื่อเราอยากอ่านแล้วไม่เชื่อคำเตือนของเบราว์เซอร์จะเกิดอะไร (ภาพบน) คำเตือนเมื่อการเชื่อมต่อถูกคั่นกลาง (ภาพล่าง) เมื่อกดยืนยันเชื่อมต่อเบราว์เซอร์ยังคงเตือนต่อไป

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

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

ความเนียนคือความท้าทาย

กระบวนการทำให้ "เนียน" เป็นหัวข้อใหญ่ในการดักฟังเว็บเข้ารหัส ที่ออกแบบมาเพื่อป้องกันการดักฟัง เว็บทั้งโลกที่เข้ารหัส ล้วนถูกตรวจสอบว่าคนที่กำลังแสดงตัวว่าเป็นเจ้าของเว็บนั้นเป็นตัวจริงหรือไม่ หน่วยงานนี้เรียกว่า Certification Authority หรือ CA ทั่วโลกมีมากมายนับไม่ถ้วน แต่ที่เบราว์เซอร์และระบบปฎิบัติการต่างๆ ให้ความเชื่อถือยอมรับว่ามีกระบวนการตรวจสอบที่ดีนั้น มีการกำหนดมาตรฐานความน่าเชื่อถือเอาไว้โดยกลุ่มร่วมระหว่างผู้ผลิตซอฟต์แวร์และหน่วยงานรับรองเว็บเอง โดยรวมทำข้อตกลงกันในชื่อหน่วยงานว่า CA Browser Forum นอกจากนี้แต่ละเบราว์เซอร์ยังกำหนดข้อตกลงเพิ่มเติมของตัวเองได้ เช่น ตัวอย่างข้อกำหนดของ Mozilla

องค์กรสามารถบังคับให้เครื่องในองค์กรเชื่อใบรับรองของเซิร์ฟเวอร์ที่คั่นกลางได้

mitmproxy เองรองรับการสร้างใบรับรองปลอมด้วย CA ของหน่วยงาน โดยสามารถสร้างใบรับรองที่รับรองโดย CA ที่ระบุได้อัตโนมัติ กระบวนการปกติแล้วจำเป็นต้องเพิ่มใบรับรองของ CA หน่วยงานนี้ให้เบราว์เซอร์ "เชื่อใจ" โดยตรง หากเป็นเครื่องในองค์กร ที่ถูกควบคุมจากฝ่ายไอที เช่น เครื่องที่อยู่ใต้โดเมน องค์กรสามารถเพิ่ม CA ของตัวเองเข้าไปให้กับทุกเครื่องได้ทันที และซอฟต์แวร์ เช่น mitmproxy ก็จะสามารถดักฟังเว็บได้โดยที่เบราว์เซอร์ไม่ขึ้นหน้าจอเตือนใดๆ กระบวนการแบบนี้ใช้กันในองค์กรขนาดใหญ่ที่ต้องการควบคุมการส่งข้อมูลออกนอกองค์กรจากเครื่องคอมพิวเตอร์ขององค์กรเอง

การบังคับบางครั้งอาจจะเป็นกระบวนการง่ายๆ คือเปิดไฟล์ CA ให้ดาวน์โหลดไปติดตั้งเอง พร้อมบอกกระบวนการติดตั้งมาให้ ควรตระหนักว่าการติดตั้งไฟล์ CA ลงเครื่องหมายถึงผู้ที่ออก CA นั้นให้เราอาจจะดักฟังเว็บใดๆ ก็ได้ตามต้องการ แม้จะเป็นเว็บเข้ารหัส

คำถามสำคัญ คือ ถ้าไม่ใช่เรื่องขององค์กรที่เข้าไปแก้ไขได้โดยตรง จะสามารถดักฟังการเข้ารหัสให้เนียนได้หรือไม่ คำตอบคือ ได้ ถ้าเราสามารถหาใบรับรองที่ "เหมือนจริง" ได้ กรณีเคยเกิดขึ้นในอิหร่าน เมื่อมีผู้พบว่ามีใบรับรองที่รับรองโดเมน google.com แต่ทางกูเกิลไม่ได้ขอ สุดท้ายพบว่าเป็นใบรับรองที่แฮกมาจาก CA ชื่อ Diginotar กระบวนการดักฟังนั้นเนียนอย่างสมบูรณ์ หากไม่ใช่เพราะว่าเบราว์เซอร์ Chrome ล็อกไว้ว่าเมื่อเป็นเว็บของกูเกิลต้องใช้ใบรับรองเฉพาะที่ระบุไว้เท่านั้น ใบรับรองอื่นๆ แม้ได้รับการรับรองมาถูกต้อง Chrome ก็จะเตือนอยู่ดี

ใบรับรองถูกต้องก็ไม่พอ

กระบวนการดักฟังการเข้ารหัสโดยไม่สามารถสังเกตได้ยังมีอีกรูปแบบหนึ่ง คือ การควบคุม CA จริงที่ไม่ได้เป็น CA สำหรับภายในองค์กรอย่างเดียว เนื่องจากระบบ CA นั้นรองรับการ "ส่งต่อสิทธิ" (delegate) ความน่าเชื่อถือไปให้หน่วยงานอื่นๆ ได้ root CA ที่ได้รับความเชื่อถือจากเบราว์เซอร์หลัก อาจจะส่งต่อสิทธิ์ให้กับหน่วยงานอื่นๆ อีกนับร้อย CA ที่ได้รับสิทธิแบบส่งต่อมาและ root CA รวมทั้งหมดที่ได้รับความเชื่อถือจากเบราว์เซอร์หลักๆ มีนับร้อยนับพันรายการ CA หลายแห่งเป็นหน่วยงานรัฐบาล ที่เคยมีประเด็นเช่น Etisalat หน่วยงานที่ได้รับสิทธิความน่าเชื่อถือต่อมาจาก CA ของบริษัท Verizon ตัว Etisalat เป็นหน่วยงานที่อยู่ใต้กำกับของรัฐบาลสหรัฐอาหรับเอมิเรตส์ EFF เคยเรียกร้องให้ Verizon ถอนสิทธิของ Etisalat เสียเพราะบริษัทเป็นผู้ให้บริการโทรศัพท์มือถือด้วย และเคยส่งอัพเดตปลอมให้กับผู้ใช้ Blackberry ในเครือข่ายนับแสนคน อย่างไรก็ดี Verizon ยังไม่ได้ถอน CA ของ Etisalat และใบรับรองที่ออกโดย Etisalat ก็ยังใช้งานได้ทั่วโลก

จนทุกวันนี้ไม่มีใครรู้แน่ชัดว่า CA ที่ได้รับสิทธิต่อมาจาก root CA มีรวมทั้งหมดจำนวนเท่าใดและมีใครบ้าง เพราะไม่มีข้อกำหนดว่า root CA ต้องประกาศ CA ที่ส่งต่อสิทธิไปให้

การได้มาซึ่งใบรับรองปลอมที่เบราว์เซอร์เชื่อถือเป็นกระบวนการที่ค่าใช้จ่ายสูงในแทบทุกทาง ไม่ว่าจะเป็นการแฮกจาก CA ซึ่งเป็นอาชญากรรม และต้องเตรียมการเป็นเวลานาน หรือการสร้าง CA แล้วซื้อสิทธิที่ได้รับส่งต่อมา กระบวนการนี้ดูจะมีประสิทธิภาพดีหากมีความต้องการที่จะดักฟังเว็บทั่วๆ ไป

กระบวนการต่อสู้กับการดักฟัง

แต่ความตระหนกว่าจะมี CA ออกใบรับรองให้กับผู้อื่นที่ไม่ใช่เจ้าของโดเมนเป็นประเด็นสำคัญทั่วโลกมาโดยเสมอ ทุกวันนี้มีการเรียกร้องให้ CA ทุกรายเปิดรายการใบรับรองที่ได้รับรองให้ไปเพื่อให้เจ้าของโดเมนสามารถตรวจสอบได้ว่ามีการออกใบรับรองอย่างไม่ถูกต้องหรือไม่ ในอีกทางหนึ่งเบราว์เซอร์เองเริ่มรองรับการ "ล็อก" CA ให้กับบางเว็บที่มีความนิยมสูง เช่นเดียวกับที่ Chrome ล็อกจนกระทั่งพบว่า DigiNotar ออกใบรับรองโดยไม่ได้รับอนุญาต ทุกวันนี้กระบวนการนี้เปิดให้เว็บขนาดใหญ่สามารถเจรจากับเบราว์เซอร์เพื่อขอให้ล็อกว่าใบรับรองของเว็บตัวเองจะออกโดย CA รายใดได้บ้าง ตัวอย่างเช่นใน Chrome 40 เป็นต้นไป เฟซบุ๊กจะออกใบรับรองได้จาก Symanctec, Digicert, และ CA สำรองของเฟซบุ๊กเองเท่านั้น โดเมนดังๆ ที่มีคนใช้จำนวนมากล้วนเจรจากับเบราว์เซอร์ในรูปแบบเดียวกับ เช่น ทวิตเตอร์, กูเกิล, Dropbox, torproject.org, หรือเว็บสำรองข้อมูลอย่าง SpiderOak สำหรับไฟร์ฟอกซ์เองก็มีนโยบายว่าเว็บใดที่ล็อก CA กับ Chrome แล้วทางไฟร์ฟอกซ์จะล็อกในแบบเดียวกัน

กระบวนการเจรจาระหว่างเว็บกับเบราว์เซอร์อาจจะใช้เวลานาน กูเกิลเสนอมาตรฐานใหม่ "Public Key Pinning Extension for HTTP" หรือ HPKP มาตั้งแต่ปี 2011 มีแนวโน้มว่าจะเป็นมาตรฐานเว็บต่อไป มาตรฐานนี้จะเปิดให้เว็บสามารถส่งข้อความแจ้งเบราว์เซอร์ได้ว่าต่อจากนี้จะมีใบรับรองใดถูกต้องบ้าง และหากพบใบรับรองที่ไม่อยู่ในรายการ สามารถเตือนให้เบราว์เซอร์แจ้งเตือนกลับไปยังเซิร์ฟเวอร์ได้ว่ามีใบรับรองน่าสงสัย ทุกวันนี้ยังคงมีเพียง Chrome (38 ขึ้นไป) และ Firefox (35 ขึ้นไป) เท่านั้นที่รองรับมาตรฐานนี้

ดักฟังกลายเป็นบล็อคเว็บ

กระบวนการดักฟังให้ผู้ใช้ไม่รู้ตัว เป็นเรื่องใหญ่ที่ต้องลงทุนสูงและมีโอกาสพลาดมากมายในช่วงหลังก แต่หากมีองค์กรที่ไม่สนใจอะไรและอยาก "ฟัง" เพียงอย่างเดียวโดยไม่สนใจว่าผู้ใช้จะรู้ตัวหรือไม่ก็ยังคงสามารถทำได้โดยลงทันไม่มากมายอะไรนัก เช่น mitmproxy ที่ยกตัวอย่างไปสามารถติดตั้งในองค์กรขนาดเล็กได้โดยง่าย

แต่มีข้อเสนอเพิ่มเติมในวงการความปลอดภัย คือ HTTP Strict Transport Security ที่เสนอโดยกูเกิล ทำให้เว็บสามารถประกาศตัวเองว่าต้องเข้ารหัสเท่านั้น ทำให้เบราว์เซอร์จะไม่พยายามเข้าเว็บนี้แบบไม่เข้ารหัสอีกเลย แม้ผู้ใช้จะพิมพ์ URL แบบไม่เข้ารหัสก็ตาม (rfc6797 ข้อ 12.1) เว็บที่ล็อก CA มักจะประกาศ HSTS อยู่เสมอ ทุกวันนี้การปลอมใบรับรองเฟซบุ๊กจึงเป็นการบล็อคเว็บไปในตัว เช่นในภาพ Chrome จะไม่แสดงปุ่ม Proceed เพื่อเข้าเว็บหากใบรับรองผิดพลาด

Get latest news form Blognone

Follow @twitterapi

สำนักข่าวWiFi Phitsanulok

ขอบคุณที่มาของข่าวโดยblognone.com ข่าวไอที
เวลาโพส2015-02-05 03:26:15