เหตุใดใบรับรอง SSL ที่ไม่ได้ลงชื่อจึงถือว่าแย่กว่าไม่มีใบรับรอง SSL


19

หากฉันดูไซต์ที่มีใบรับรอง SSL ที่ไม่ได้ลงชื่อหรือลงนามเองเบราว์เซอร์ของฉันจะเตือนฉัน เบราว์เซอร์ตัวเดียวกันไม่มีปัญหาในการอนุญาตให้ส่งข้อมูลประจำตัวในหน้าที่ไม่ปลอดภัย

เหตุใดใบรับรองที่ลงนามเองจึงถือว่าเลวร้ายยิ่งกว่าไม่มีใบรับรอง

คำตอบ:


16

มีคนมากมายที่รู้สึกว่าระบบนี้พัง

นี่คือตรรกะที่อยู่เบื้องหลังว่าทำไมเบราว์เซอร์ของคุณจะให้คำเตือนที่น่าตกใจเมื่อใบรับรอง SSL ไม่ถูกต้อง:

หนึ่งในวัตถุประสงค์การออกแบบดั้งเดิมของโครงสร้างพื้นฐาน SSL คือการให้การรับรองความถูกต้องของเว็บเซิร์ฟเวอร์ โดยทั่วไปถ้าคุณไปที่ www.bank.com SSL จะช่วยให้เว็บเซิร์ฟเวอร์ที่ตอบสนองเพื่อพิสูจน์ว่าจริงแล้วมันเป็นของธนาคารของคุณ วิธีนี้จะหยุดการแอบอ้างไม่ให้จัดการ DNS หรือใช้วิธีอื่นเพื่อให้เซิร์ฟเวอร์ที่เป็นอันตรายตอบสนอง

"ความน่าเชื่อถือ" ใน SSL นั้นให้บริการโดยการมีบุคคลที่สามที่เชื่อถือได้ (บริษัท เช่น VeriSign และ Thawte Consulting) ลงนามในใบรับรองซึ่งบ่งชี้ว่าพวกเขาได้ตรวจสอบแล้วว่าเป็นของใครเป็นเจ้าของ (ในทางทฤษฎีโดยไปที่ผู้ดูแลระบบไอที บุคคลหรือวิธีการอื่นที่สร้างความเชื่อมั่นโดยตรงแม้ว่าหลักฐานแสดงให้เห็นว่าพวกเขาค่อนข้างหละหลวมเกี่ยวกับเรื่องนี้ - สิ่งที่ต้องทำเพื่อให้ได้รับใบรับรอง SSL ที่เซ็นชื่อมักจะมีจำนวน 800 และทักษะการแสดงเล็กน้อย)

ดังนั้นหากคุณเชื่อมต่อกับเว็บเซิร์ฟเวอร์ที่ให้ใบรับรอง SSL แต่ไม่ได้ลงนามโดยบุคคลที่สามที่เชื่อถือได้ในทางทฤษฎีนี่อาจหมายความว่าคุณกำลังสื่อสารกับผู้แอบอ้างที่อ้างว่าเป็นเซิร์ฟเวอร์ที่อยู่ในองค์กรอื่น .


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

ฉันเองเชื่อว่าระบบนี้ใช้งานไม่ได้และการสื่อสารกับเซิร์ฟเวอร์ที่ไม่มีการเข้ารหัสนั้นอันตรายกว่าการสื่อสารกับเซิร์ฟเวอร์ที่เสนอ SSL ด้วยใบรับรองที่ลงชื่อด้วยตนเอง มีเหตุผลสามประการที่เบราว์เซอร์ไม่ทำงานเช่นนี้:

  1. การสื่อสารที่ไม่ได้เข้ารหัสเป็นบรรทัดฐานบนอินเทอร์เน็ตดังนั้นหากเบราว์เซอร์ทำให้คุณคลิกผ่านคำเตือนเพื่อดูเว็บไซต์ที่ไม่มีการเข้ารหัสคุณจะได้รับความรำคาญอย่างรวดเร็วและปิดการใช้งานคำเตือน
  2. เนื่องจากคำเตือนที่น่ากลัวแก่ลูกค้าเป็นเรื่องผิดปกติที่จะเห็นใบรับรองที่ลงนามด้วยตนเองในเว็บไซต์การผลิต สิ่งนี้สร้างระบบการทำให้ถาวรด้วยตนเอง: ใบรับรองที่ลงชื่อด้วยตัวเองนั้นน่าสงสัยเพราะมันหายากมันหายากเพราะมันน่าสงสัย
  3. นี่คือเหยียดหยามทำให้เกิดเสียงของฉัน แต่มี บริษัท ที่โดดเด่นที่จะทำให้การจัดการที่ดีของเงินออกจากการลงนามในใบรับรอง SSL ( ไอ Verisign ไอ ) เพื่อให้พวกเขาใช้ whitepapers (ไอทีระยะหมายถึง "ความยาวและน่าเบื่อโฆษณา") และสิ่งพิมพ์อื่น ๆ เพื่อบังคับใช้ความคิดที่ว่าใบรับรองที่ไม่ได้ลงชื่อนั้นเป็นอันตราย

5
หากปราศจากความน่าเชื่อถือซึ่งเป็นสิ่งที่คุณได้รับจากใบรับรองที่ลงนามโดย CA และไม่ใช่การเซ็นชื่อด้วยตนเองคุณจะไม่สามารถตรวจสอบว่าเซิร์ฟเวอร์ที่คุณกำลังเชื่อมต่ออยู่นั้นเป็นใคร ใบรับรองที่ลงนามเองนั้นเป็นอันตรายในแง่ที่ว่าพวกเขาไม่ได้ให้วิธีการใด ๆ สำหรับผู้ใช้ในการตรวจสอบว่าข้อมูลที่พวกเขากำลังส่งถึงปลายทางที่พวกเขากล่าวว่ามันเป็น ผู้คนเริ่มเรียนรู้ที่จะมองหา "https" เมื่อทำธุรกรรมที่ปลอดภัยดังนั้นการเตือนใหญ่เกี่ยวกับใบรับรองที่ไม่ถูกต้องหรือลงนามด้วยตนเองนั้นได้รับการรับประกัน 100% เพราะพวกเขาสูญเสียหนึ่งในผลประโยชน์หลักของ SSL
MDMarra

ฉันจะไม่พูดว่า 'แตก' ฉันคิดว่าส่วนเสริมของ Firefox Certificate Patrol นั้นใกล้เคียงกับการนำใบรับรองไปใช้อย่างถูกต้องและจัดการความน่าเชื่อถือมากกว่าค่าเริ่มต้น ถึงกระนั้นค่าเริ่มต้นก็ยังดีกว่าไม่สนใจเครือข่ายที่น่าเชื่อถือทั้งหมด
Slartibartfast

4
@MarkM - ความรู้สึกของฉันคือการพิสูจน์ตัวตนไม่ควรพิจารณาถึงประโยชน์หลักของ SSL ฉันไม่มีข้อมูลสำรอง แต่ฉันคิดว่าเหตุการณ์ความปลอดภัยที่มากขึ้นเป็นผลมาจากการถ่ายโอนข้อมูลผ่านการเชื่อมต่อที่ไม่ได้เข้ารหัส (ตัวอย่างเช่นวิศวกรความปลอดภัยของ Facebook ที่ขโมยรหัสผ่าน - พวกเขาดมรหัสผ่านของเครือข่าย wifi เนื่องจากการเข้าสู่ระบบ Facebook ไม่ได้เข้ารหัส) กว่าผ่าน MitM หรือการโจมตีแบบแอบอ้างซึ่งมีความซับซ้อนมากในการใช้งาน การมุ่งเน้นไปที่การตรวจสอบความถูกต้องของการเข้ารหัสใน SSL คือสิ่งที่สร้างขึ้นในสถานการณ์นี้
jcrawfordor

1
@MarkM - ในขณะที่มีค่าใช้จ่ายอย่างแน่นอนซึ่งเป็นข้อกังวลที่ถูกต้องตามกฎหมายการใช้ certs ที่ไม่ได้ลงชื่อจะไม่ทำให้เกิดความเครียดกับ CA โดยเฉพาะเพราะ CA จะไม่ถูกใช้สำหรับใบรับรองที่ลงนามด้วยตนเอง นอกจากนี้สำหรับองค์กรที่มีพลังงานเพียงพอไม่ต้องกังวลลองพิจารณาว่า Google ใช้ค่าเริ่มต้นเป็น https สำหรับ gmail และบริการอื่น ๆ ฉันเข้าใจจุดของคุณว่าไม่มีการตรวจสอบสิทธิ์ SSL มีประโยชน์ลดลง รุ่นปัจจุบันไม่ได้รับการออกแบบอย่างดี สิ่งที่เราต้องการจริงๆคือโปรโตคอลที่เข้ารหัสมาตรฐานและโปรโตคอลที่ได้รับการรับรองสำหรับการใช้งานที่ปลอดภัยยิ่งขึ้น
nhinkle

5
ความสำคัญของประเด็นของฉันมากขึ้นและ NRHinkle โดยตรงกล่าวสิ่งนี้คือเราต้องเริ่มพิจารณาการเข้ารหัสและการรับรองความถูกต้องเป็นเป้าหมายที่แยกต่างหากและอนุญาตให้พวกเขาแยกจากกัน สิ่งเหล่านี้เป็นข้อบกพร่องพื้นฐานกับระบบ SSL ในขณะนี้: 1) เราเห็นการเข้ารหัสและการรับรองความถูกต้องที่แนบมาอย่างแยกไม่ออก - เพื่อให้บรรลุหนึ่งคุณต้องบรรลุอีก การให้เพียงคนเดียวคือ 'น่าสงสัย' 2) การรับรองความถูกต้องจะต้องได้รับจาก CA ที่แสวงหาผลกำไรในจำนวนที่ จำกัด โดยทั่วไปแล้ว CAs มีราคาแพงมาก (Verisign ฯลฯ ) หรือร่มรื่นมาก (NameCheap เป็นต้น)
jcrawfordor

6

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

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


ยุติธรรมพอสำหรับฉัน
dag729

เป็นเรื่องของความเป็นจริงผมจำได้ว่าอย่างน้อยรุ่นเก่าของ Netscape Navigator ไม่ปรากฏขึ้นคำเตือนสำหรับทุกโพสต์ที่ไม่ได้เข้ารหัส แน่นอนว่าทุกคนปิดการใช้งานพวกเขาหลังจากห้านาทีดังนั้นฉันเดาว่าทำไมพวกเขาเอามันออก ...
sleske

4

ฉันไม่สามารถแสดงความคิดเห็นดังนั้นฉันจะโพสต์ข้อมูลนี้ซึ่งเติมเต็มข้อมูลที่ถูกต้องของ user40350

เบราว์เซอร์ตัวเดียวกันไม่มีปัญหาในการอนุญาตให้ส่งข้อมูลประจำตัวในหน้าที่ไม่ปลอดภัย

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

Miro A wrote:

การส่งข้อมูลประจำตัวจากหน้าหนึ่งไปยังอีกหน้าหนึ่งกำลังทำ HTTP POST ไม่มีอะไรพิเศษเกี่ยวกับการส่งข้อมูลประจำตัวเมื่อเปรียบเทียบกับการส่งเช่นคำค้นหาผ่าน POST

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


3

การเชื่อมต่อที่ปลอดภัยโดยโปรโตคอล https: // จะถูกระบุโดยเบราว์เซอร์ที่จะ "ปลอดภัย" ตัวอย่างเช่นจะแสดง Padlock เล็ก ๆ น้อย ๆ หรือบางส่วนของ URL ถูกทำเครื่องหมายเป็นสีเขียว

ผู้ใช้ควรเชื่อใจว่าหน้าที่เขาเยี่ยมชมนั้นมาจาก URL ที่เขาป้อนและไม่ได้มาจากบุคคลอื่น

หากเขาไม่ใช้ https: // ผู้ใช้ควรรู้ว่าข้อมูลที่ป้อนนั้นไม่ได้รับการป้องกันและไซต์ที่เขาท่องอาจถูกปลอมแปลง

ใบรับรองที่ลงนามด้วยตนเองไม่แน่ใจ - คาดหวังอีกครั้งว่าหน้าเว็บที่เปิดไปยังไม่ได้ทำการปลอมแปลงดังนั้นจึงไม่มีความปลอดภัยเพิ่มขึ้น


1

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

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


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

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

นอกจากนี้ในฐานะผู้ใช้ฉันรู้จริง ๆ ว่า Verisign คือใครและทำไมฉันจึงควรเชื่อถือพวกเขา ความสนใจของพวกเขาในการขายใบรับรองสูงกว่าการถือครองใบรับรองนั้นรับผิดชอบต่อการใช้ข้อมูลที่คุณส่งไปในทางที่ผิดหรือไม่?
Dmitry

0

เหตุผลที่ดีมากมายได้รับการจดทะเบียน นี่คืออีกหนึ่ง:

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

นี่คือตัวอย่างที่เหมือนจริง สมมติว่าฉันเป็นผู้ขายและฉันมีลิงก์ 'ชำระเงินด้วย PayPal' คุณคลิกที่และฉันรู้ ฉันนำคุณไปสู่ ​​PayPal และให้คุณได้รับหน้า PayPal ที่ปลอดภัยและถูกกฎหมาย หากฉันกำลังดูเครือข่ายของคุณฉันรู้ว่าจะเป็นคำขอแรกของคุณจาก PayPal และไม่นานหลังจากนั้นคุณจะส่งรหัสผ่านของคุณ ดังนั้นฉันจึง MITM ที่submitมีที่อยู่อีเมลและรหัสผ่านของคุณแทนใบรับรองการลงนามด้วยตนเองสำหรับ PayPal

คุณเห็นว่าการรักษาความปลอดภัยของหน้าเว็บด้านนอกถูกประนีประนอมโดยไม่เตือนถ้าใบรับรองของหน้าด้านในมีการเซ็นชื่อด้วยตนเอง? ดังนั้นจึงต้องเตือนเกี่ยวกับใบรับรองที่ลงชื่อด้วยตนเองที่มาจากลิงก์

และแน่นอนถ้าคุณป้อนhttpsด้วยตนเองมันจะต้องเตือนคุณ เพราะคุณคาดหวังว่ามันจะปลอดภัย


-1

เมื่อมนุษย์ในการโจมตีกลางถูกดำเนินการใน https: // เว็บไซต์คำเตือนจะบ่งบอกถึงสิ่งที่ผิดปกติกับผู้ใช้โดยเฉลี่ยเท่านั้น ดังนั้นจึงเป็นส่วนสำคัญของความปลอดภัย HTTPS

คำถามที่ดีคือสาเหตุที่การเข้ารหัสที่ไม่ปลอดภัยบางส่วนนั้นไม่สามารถทำได้ผ่าน HTTP

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.