เนื่องจากข้อมูลส่วนตัวที่ไหลผ่านกลุ่มท่อขนาดใหญ่ที่เป็นอินเทอร์เน็ต การเข้ารหัสไม่ใช่สิ่งที่เราทำได้หรือไม่ควรเพิกเฉย เบราว์เซอร์ที่ทันสมัยมีกลไกหลายอย่างที่คุณใช้เพื่อให้มั่นใจว่าข้อมูลของผู้ใช้มีความปลอดภัยขณะรับส่งได้ เช่น คุกกี้ที่ปลอดภัยและ Strict Transport Security เป็น 2 สิ่งที่สำคัญที่สุด ซึ่งช่วยให้คุณปกป้องผู้ใช้ได้อย่างราบรื่น อัปเกรดการเชื่อมต่อเป็น HTTPS และรับประกันว่าจะไม่มีการส่งข้อมูลผู้ใช้ที่ชัดเจน
สาเหตุที่ไม่ควรพลาดผลิตภัณฑ์นี้ ลองพิจารณาสิ่งเหล่านี้
การส่งหน้าเว็บผ่านการเชื่อมต่อ HTTP ที่ไม่ได้เข้ารหัสมีมากหรือน้อยไม่ต่างจากการยื่นซองจดหมายที่ไม่ได้ปิดผนึกแก่บุคคลแรกที่คุณเห็นบนท้องถนนซึ่งดูเหมือนว่าเธอกำลังเดินไปตามที่ทำการไปรษณีย์ ถ้าคุณโชคดี เธออาจทำทุกอย่างด้วยตัวเอง หรืออาจส่งต่อให้คนถัดไปที่เห็นว่าใครมาถูกทางแล้ว บุคคลนั้นอาจทำ แบบเดียวกันและต่อไปเรื่อยๆ
คนแปลกหน้าส่วนใหญ่ในกลุ่มธุรกิจแบบเร่งด่วนนี้น่าเชื่อถือ และไม่เคยเห็นจดหมายเปิดหรือปรับเปลี่ยนจดหมายของคุณ แต่ยิ่งจดหมายเปลี่ยนมือมากเท่าใด จำนวนผู้ที่มีสิทธิ์เข้าถึงจดหมายที่คุณกำลังส่งอย่างสมบูรณ์ก็ยิ่งมีมากขึ้นเท่านั้น ในท้ายที่สุด ก็มีแนวโน้มว่าผู้รับจดหมายของคุณจะได้รับบางอย่างทางไปรษณีย์ แต่หากมีบางอย่างที่เหมือนกันกับที่คุณส่งไปตั้งแต่แรก จะเป็นคำถามที่เปิดกว้าง คุณน่าจะปิดซองจดหมายนั้นแล้ว...
พ่อค้าคนกลาง
อินเทอร์เน็ตจำนวนมากจะต้องอาศัยความน่าเชื่อถือของคนแปลกหน้า ไม่ว่าจะดีขึ้นหรือแย่ลง เซิร์ฟเวอร์ไม่ได้เชื่อมต่อกันโดยตรง แต่จะส่งคำขอและการตอบกลับจากเราเตอร์ไปยังเราเตอร์ในเกมโทรศัพท์ขนาดมหึมา
คุณดูการรับส่งเหล่านี้ได้ด้วยคำสั่ง trackRoute เส้นทางจากคอมพิวเตอร์ของฉันไปยัง HTML5Rocks จะมีลักษณะดังนี้
$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
1 router1-lon.linode.com (212.111.33.229) 0.453 ms
2 212.111.33.233 (212.111.33.233) 1.067 ms
3 217.20.44.194 (217.20.44.194) 0.704 ms
4 google1.lonap.net (193.203.5.136) 0.804 ms
5 209.85.255.76 (209.85.255.76) 0.925 ms
6 209.85.253.94 (209.85.253.94) 1.226 ms
7 209.85.240.28 (209.85.240.28) 48.714 ms
8 216.239.47.12 (216.239.47.12) 22.575 ms
9 209.85.241.193 (209.85.241.193) 36.033 ms
10 72.14.233.180 (72.14.233.180) 43.222 ms
11 72.14.233.170 (72.14.233.170) 43.242 ms
12 *
13 lb-in-f102.1e100.net (173.194.71.102) 44.523 ms
การขว้างลูก 13 ครั้งไม่เลวเลยทีเดียว แต่ถ้าฉันส่งคำขอผ่าน HTTP เราเตอร์ระดับกลางแต่ละตัวจะเข้าถึงคำขอของฉันและการตอบกลับของเซิร์ฟเวอร์ได้อย่างสมบูรณ์ ข้อมูลทั้งหมดกำลังถูกถ่ายโอนเป็นข้อความธรรมดาที่ไม่ได้เข้ารหัส และคนกลางเหล่านั้นสามารถทำหน้าที่เป็นชายในตอนกลาง อ่านข้อมูลของฉัน หรือแม้กระทั่งจัดการข้อมูลนั้นระหว่างการส่ง
ที่แย่กว่านั้นคือ การดักจับในลักษณะนี้แบบแทบไม่สามารถตรวจจับได้ การตอบกลับ HTTP ที่แก้ไขแล้วที่เป็นอันตรายมีลักษณะเหมือนการตอบกลับที่ถูกต้องทุกประการ เนื่องจากไม่มีกลไกใดที่จะช่วยให้คุณมั่นใจได้ว่าข้อมูลที่ได้รับนั้นเป็นข้อมูลที่ส่ง _exactly _ ถ้ามีคนตัดสินใจเปลี่ยนอินเทอร์เน็ตของฉันกลับหัวเพื่อหัวเราะ ฉันก็เลยอาจหรืออาจโชคไม่ดีนัก
สายนี้เป็นสายที่ปลอดภัยไหม
การเปลี่ยนจาก HTTP แบบข้อความธรรมดาเป็นการเชื่อมต่อ HTTPS ที่ปลอดภัยจะมอบการป้องกันที่ดีที่สุดจากคนกลาง การเชื่อมต่อ HTTPS จะเข้ารหัสทั้งแชแนลจากต้นทางถึงปลายทางก่อนที่จะส่งข้อมูล ทำให้คอมพิวเตอร์ระหว่างคุณกับปลายทางไม่สามารถอ่านหรือแก้ไขข้อมูลที่อยู่ระหว่างการส่งได้
ความปลอดภัยที่ HTTPS มีให้นั้นมาจากแนวคิดของคีย์การเข้ารหัสสาธารณะและส่วนตัว การพูดคุยเรื่องรายละเอียดในเชิงลึกนั้นอยู่นอกเหนือขอบเขตของบทความนี้เป็นอย่างดี แต่หลักการสำคัญค่อนข้างตรงไปตรงมา คือข้อมูลที่เข้ารหัสด้วยคีย์สาธารณะหนึ่งๆ จะถอดรหัสได้ด้วยคีย์ส่วนตัวที่เกี่ยวข้องเท่านั้นเท่านั้น เมื่อเบราว์เซอร์เริ่มแฮนด์เชค HTTPS เพื่อสร้างช่องทางที่ปลอดภัย เซิร์ฟเวอร์จะให้ใบรับรองซึ่งให้ข้อมูลทั้งหมดที่จำเป็นในการยืนยันตัวตนของเบราว์เซอร์โดยตรวจสอบว่าเซิร์ฟเวอร์ครอบครองคีย์ส่วนตัวที่ถูกต้องแล้ว การสื่อสารทั้งหมดจากจุดนั้นจะได้รับการเข้ารหัสในลักษณะที่พิสูจน์ว่ามีการส่งคำขอไปยังและการตอบกลับจากเซิร์ฟเวอร์ที่ตรวจสอบสิทธิ์แล้ว
ดังนั้น HTTPS จะช่วยให้คุณมั่นใจว่าคุณกำลังพูดคุยกับเซิร์ฟเวอร์ที่คิดว่ากำลังพูดอยู่ และไม่มีใครฟังหรือบิดเบี้ยวบนสายไฟอยู่ การเข้ารหัสประเภทนี้เป็นสิ่งจำเป็นเบื้องต้นเพื่อความปลอดภัยบนเว็บ หากปัจจุบันแอปพลิเคชันของคุณไม่ได้แสดงผ่าน HTTPS ก็อาจมีช่องโหว่ที่จะถูกโจมตี แก้ไข Ars Technica มีคู่มือที่ยอดเยี่ยมในการรับและติดตั้งใบรับรอง (ฟรี) ซึ่งเราขอแนะนำให้คุณดูรายละเอียดทางเทคนิค การกำหนดค่าจะแตกต่างกันไปตามผู้ให้บริการและเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ แต่กระบวนการส่งคำขอใบรับรองจะเหมือนกันทุกที่
ปลอดภัยอุ่นใจเสมอ
เมื่อคุณส่งคำขอและติดตั้งใบรับรองแล้ว ตรวจสอบให้แน่ใจว่าผู้ใช้ของคุณจะได้รับประโยชน์จากการทำงานหนักของคุณ โดยย้ายข้อมูลผู้ใช้ที่มีอยู่ไปยังการเชื่อมต่อ HTTPS อย่างโปร่งใสผ่านการเปลี่ยนเส้นทาง HTTP และตรวจสอบว่ามีการส่งคุกกี้ผ่านการเชื่อมต่อที่ปลอดภัยเท่านั้น
ด้วยวิธีนี้
เมื่อผู้ใช้เข้าชม http://example.com/ ให้เปลี่ยนเส้นทางผู้ใช้ไปที่ https://example.com/ โดยการส่งการตอบกลับ 301 Moved
Permanently ที่มีส่วนหัว Location ที่เหมาะสมดังนี้
$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/
คุณสามารถตั้งค่าการเปลี่ยนเส้นทางประเภทนี้ได้อย่างง่ายดายในเซิร์ฟเวอร์ เช่น Apache หรือ Nginx
เช่น การกำหนดค่า Nginx ที่เปลี่ยนเส้นทางจาก http://example.com/ ไปยัง https://example.com/ จะมีลักษณะดังนี้
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
ล็อกโหลคุกกี้
คุกกี้ช่วยให้เราสามารถมอบประสบการณ์การลงชื่อเข้าสู่ระบบที่ราบรื่น ผ่านโปรโตคอล HTTP แบบไม่เก็บสถานะ ข้อมูลที่จัดเก็บในคุกกี้ รวมถึงข้อมูลที่ละเอียดอ่อน เช่น รหัสเซสชัน จะส่งไปพร้อมกับคำขอทุกรายการ ซึ่งทำให้เซิร์ฟเวอร์ทราบว่ากำลังตอบกลับผู้ใช้รายใดอยู่ เมื่อเรามั่นใจว่าผู้ใช้เข้าถึงเว็บไซต์ของเราผ่าน HTTPS แล้ว เราควรตรวจสอบด้วยว่าข้อมูลที่ละเอียดอ่อนซึ่งจัดเก็บไว้ในคุกกี้จะได้รับการถ่ายโอนผ่านการเชื่อมต่อที่ปลอดภัยเท่านั้น และจะไม่มีการส่งข้อมูลอย่างเปิดเผย
โดยทั่วไป การตั้งค่าคุกกี้จะเกี่ยวข้องกับส่วนหัว HTTP ที่มีลักษณะดังนี้
set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT
คุณสามารถสั่งให้เบราว์เซอร์จำกัดการใช้คุกกี้เพื่อรักษาความปลอดภัยของเซสชันได้โดยบันทึกคีย์เวิร์ดคำเดียว ดังนี้
Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure
คุกกี้ที่ตั้งค่าด้วยคีย์เวิร์ดที่ปลอดภัยจะไม่ส่งผ่าน HTTP เป็นอันขาด
การปิดหน้าต่างที่เปิดอยู่
การเปลี่ยนเส้นทางแบบโปร่งใสไปยัง HTTPS หมายความว่าโดยส่วนใหญ่แล้วผู้ใช้จะใช้การเชื่อมต่อที่ปลอดภัย อย่างไรก็ตาม ยังทิ้งโอกาสการโจมตีเล็กๆ น้อยๆ ไว้ กล่าวคือ การเชื่อมต่อ HTTP เริ่มต้นนั้นเปิดอยู่แบบกว้างๆ, เสี่ยงต่อการมีการตัด SSL และการโจมตีที่เกี่ยวข้อง เนื่องจากผู้ชายที่อยู่ตรงกลางเข้าถึงคำขอ HTTP เริ่มต้นได้โดยสมบูรณ์ คำขอ HTTP เริ่มต้นจึงเป็นพร็อกซีระหว่างคุณกับเซิร์ฟเวอร์ที่จะทำให้คุณเชื่อมต่อ HTTP ที่ไม่ปลอดภัยได้ไม่ว่าเซิร์ฟเวอร์จะมีเจตนาใดก็ตาม
คุณลดความเสี่ยงของการโจมตีประเภทนี้ได้โดยขอให้เบราว์เซอร์บังคับใช้ HTTP Strict Transport Security (HSTS) การส่งส่วนหัว HTTP ของ Strict-Transport-Security จะสั่งให้เบราว์เซอร์ทำการเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS ฝั่งไคลเอ็นต์ โดยไม่ต้องแตะเครือข่ายเลย (กรณีนี้ทำให้มีประสิทธิภาพที่ดี คำขอที่ดีที่สุดคือคุณไม่ต้องสร้าง) ดังนี้
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
เบราว์เซอร์ที่รองรับส่วนหัวนี้ (ปัจจุบันคือ Firefox, Chrome และ Opera: caniuse มีรายละเอียด) จะหมายเหตุว่าเว็บไซต์นี้ได้ขอสิทธิ์เข้าถึง HTTPS เท่านั้น ซึ่งหมายความว่าไม่ว่าผู้ใช้จะเข้าชมเว็บไซต์นั้นด้วยวิธีใด ผู้ใช้ก็จะเข้าชมผ่าน HTTPS เท่านั้น ถึงแม้ว่าเธอจะพิมพ์ http://example.com/ ลงในเบราว์เซอร์ สุดท้ายเธอก็จะไปที่ HTTPS โดยไม่ทำการเชื่อมต่อ HTTP เลย ยิ่งไปกว่านั้น หากเบราว์เซอร์ตรวจพบใบรับรองที่ไม่ถูกต้อง (อาจพยายามปลอมแปลงตัวตนของเซิร์ฟเวอร์) ผู้ใช้จะไม่สามารถดำเนินการต่อผ่าน HTTP ได้ ซึ่งยอดเยี่ยมมาก
สถานะ HSTS ของเซิร์ฟเวอร์จะหมดอายุหลังจากผ่านไป max-age วินาที (ในตัวอย่างนี้ประมาณ 1 เดือน) ให้กำหนดค่านี้ให้อยู่ในระดับที่ค่อนข้างสูง
นอกจากนี้ คุณยังมั่นใจได้ว่าโดเมนย่อยทั้งหมดของต้นทางได้รับการปกป้องโดยเพิ่มคำสั่ง includeSubDomains ลงในส่วนหัว
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
ออกเดินทางอย่างปลอดภัย
HTTPS วิธีเดียวที่จะช่วยให้คุณตรวจสอบจากระยะไกลได้ว่าข้อมูลที่คุณส่งถึงผู้รับที่กำหนดไว้ยังคงเดิม คุณควรทำการเชื่อมต่อที่ปลอดภัย
สำหรับเว็บไซต์และแอปพลิเคชันวันนี้เลย วิธีนี้ค่อนข้างตรงไปตรงมาและจะช่วย
รักษาข้อมูลของลูกค้าให้ปลอดภัย เมื่อคุณมีแชแนลที่เข้ารหัสเรียบร้อยแล้ว คุณควรเปลี่ยนเส้นทางผู้ใช้ไปยังการเชื่อมต่อที่ปลอดภัยนี้อย่างโปร่งใส ไม่ว่าผู้ใช้จะเข้ามาที่เว็บไซต์ของคุณอย่างไรด้วยการส่งการตอบกลับ HTTP 301 จากนั้นตรวจสอบว่าข้อมูลเซสชันที่ละเอียดอ่อนของผู้ใช้ทั้งหมดใช้การเชื่อมต่อที่ปลอดภัยนั้นเท่านั้นด้วยการเพิ่มคีย์เวิร์ดที่ปลอดภัยเมื่อตั้งค่าคุกกี้
เมื่อทำทุกอย่างเรียบร้อยแล้ว อย่าลืมตรวจสอบว่าผู้ใช้ไม่ได้ตกจากรถประจำทางโดยไม่ตั้งใจ ปกป้องผู้ใช้ด้วยการตรวจสอบว่าเบราว์เซอร์ของผู้ใช้ทำสิ่งที่ถูกต้องด้วยการส่งส่วนหัว Strict-Transport-Security
การตั้งค่า HTTPS ไม่ใช่เรื่องง่ายนัก และมีประโยชน์อย่างมากต่อเว็บไซต์และผู้ใช้ คุ้มค่ากับความพยายาม
แหล่งข้อมูล
- StartSSL มีใบรับรองที่ยืนยันด้วยโดเมนฟรี ของฟรีไม่มีวันหมด แน่นอนว่าการก้าวไปสู่ระดับที่สูงขึ้นของการยืนยันนั้น มีราคาที่เป็นไปได้และมีราคาที่สมเหตุสมผล
- การทดสอบเซิร์ฟเวอร์ SSL: เมื่อคุณตั้งค่า HTTPS สำหรับเซิร์ฟเวอร์แล้ว โปรดยืนยันว่าคุณได้ทำอย่างถูกต้องโดยการเรียกใช้ผ่านการทดสอบเซิร์ฟเวอร์ของ SSL Labs คุณจะได้รับรายงานที่มีรายละเอียดมากซึ่งแสดงให้เห็นว่าคุณพร้อมสำหรับการใช้งานจริงหรือไม่
- บทความล่าสุดของ Ars Technica "การรักษาความปลอดภัยเว็บเซิร์ฟเวอร์ด้วย SSL/TLS" ควรอ่านเพื่อดูรายละเอียดเพิ่มเติมเกี่ยวกับน็อตและน็อตของการตั้งค่าเซิร์ฟเวอร์
- ข้อกำหนดเกี่ยวกับความปลอดภัยที่เข้มงวดในการรับส่งข้อมูลแบบ HTTP (RFC6797) ควรอ่านข้อมูลทางเทคนิคทั้งหมดที่เกี่ยวกับส่วนหัว
Strict-Transport-Securityที่คุณอาจต้องการ - เมื่อคุณรู้แล้วว่าตัวเองกำลังทำอะไรอยู่ ขั้นตอนต่อไปที่เป็นไปได้ก็คือการโฆษณาว่าเว็บไซต์ของคุณควรเข้าถึงได้ผ่านชุดใบรับรองที่เฉพาะเจาะจงเท่านั้น ตอนนี้ IETF มีการดำเนินการบางอย่างซึ่งจะให้คุณทำได้ผ่านส่วนหัว
Public-Key-Pinsแม้จะอยู่ในช่วงเริ่มต้นแต่ก็น่าสนใจและน่าติดตาม