1019

URL ทั้งหมดถูกเข้ารหัสเมื่อใช้การเข้ารหัส TLS / SSL (HTTPS) หรือไม่ ฉันอยากรู้เพราะฉันต้องการซ่อนข้อมูล URL ทั้งหมดเมื่อใช้ TLS / SSL (HTTPS)

หาก TLS / SSL ให้การเข้ารหัส URL ทั้งหมดคุณไม่ต้องกังวลเกี่ยวกับการซ่อนข้อมูลที่เป็นความลับจาก URL

ssl https httprequest

— Daniel Kivatinos
แหล่งที่มา

76

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

— jalf

43

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

— Piskvor ออกจากอาคาร

47

https://somewhere_i_trust/ways_to_protest_against_the_government/ตัวอย่างเช่นสมมติว่าเราจะไปเยี่ยม URL นั้นมีข้อมูลที่เป็นความลับคือข้อเสนอแนะที่ฉันกำลังพิจารณาที่จะคัดค้านรัฐบาล

— Steve Jessop

42

ฉันถามตัวเองคำถามนี้เมื่อทำการร้องขอ HTTP จากแอปที่ไม่ใช่เบราว์เซอร์ ฉันเดาว่านี่อาจเป็นสิ่งที่นักพัฒนาแอพมือถือสนใจ ในกรณีนี้ความคิดเห็นด้านบน (ในขณะที่เป็นจริง) นั้นไม่เกี่ยวข้อง (ไม่เห็น URL ไม่มีประวัติการเรียกดู) ทำให้คำตอบเพื่อให้เข้าใจง่าย: "ใช่มันถูกเข้ารหัส"

— DannyA

23

สำหรับผู้ที่คิดว่าเมื่อคุณเป็น HTTPS ไม่มีใครรู้ว่าที่คุณกำลังจะอ่านครั้งแรกนี้:ชื่อโฮสต์ของเซิร์ฟเวอร์ (เช่น example.com) จะยังคงรั่วไหลออกมาเนื่องจาก SNI สิ่งนี้ไม่มีอะไรเกี่ยวข้องกับ DNS และการรั่วไหลจะเกิดขึ้นแม้ว่าคุณจะไม่ได้ใช้ DNS หรือใช้ DNS ที่เข้ารหัส

— Pacerier

913

ใช่การเชื่อมต่อ SSL อยู่ระหว่างเลเยอร์ TCP และเลเยอร์ HTTP ไคลเอ็นต์และเซิร์ฟเวอร์จะสร้างการเชื่อมต่อ TCP ที่เข้ารหัสลับอย่างปลอดภัย (ผ่านโปรโตคอล SSL / TLS) จากนั้นไคลเอ็นต์จะส่งการร้องขอ HTTP (GET, POST, DELETE ... ) ผ่านการเชื่อมต่อ TCP ที่เข้ารหัส

— Marc Novakowski
แหล่งที่มา

98

ยังคงคุ้มค่าที่จะสังเกตสิ่งที่ @Jalf พูดถึงในความคิดเห็นเกี่ยวกับคำถามนั้น ข้อมูล URL จะถูกบันทึกไว้ในประวัติของเบราว์เซอร์ซึ่งอาจไม่ปลอดภัยในระยะยาว

— Michael Ekstrand

20

ไม่ใช่แค่รับหรือโพสต์ อาจเป็น DELETE, PUT, HEAD หรือ TRACE

4

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

— zingle-dingle

28

อย่างไรก็ตามโปรดทราบว่าการแก้ไข DNS ของ URL อาจไม่ได้เข้ารหัส ดังนั้นใครบางคนที่ดมทราฟฟิกของคุณอาจยังเห็นโดเมนที่คุณพยายามเข้าถึง

— ChewToy

21

SNI แบ่งส่วน 'โฮสต์' ของการเข้ารหัส SSL ของ URL คุณสามารถทดสอบด้วยตัวคุณเองด้วย wireshark มีตัวเลือกสำหรับ SNI หรือคุณสามารถตรวจสอบแพ็กเก็ต SSL ของคุณเมื่อคุณเชื่อมต่อกับโฮสต์ระยะไกล

— cmouse

654

เนื่องจากไม่มีใครให้การดักสายนี่เป็นเรื่องหนึ่ง
Name Server (ส่วนหนึ่งของโดเมนของ URL) ที่จะนำเสนอในClientHelloแพ็คเก็ตในข้อความธรรมดา

ต่อไปนี้แสดงคำขอเบราว์เซอร์ไปที่:
https://i.stack.imgur.com/path/?some=parameters&go=here

ดูคำตอบนี้สำหรับข้อมูลเพิ่มเติมเกี่ยวกับฟิลด์เวอร์ชัน TLS (มี 3 รายการ - ไม่ใช่เวอร์ชันฟิลด์ที่แต่ละหมายเลขมีหมายเลขเวอร์ชัน!)

จากhttps://www.ietf.org/rfc/rfc3546.txt :

3.1 บ่งชี้ชื่อเซิร์ฟเวอร์

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

เพื่อให้ชื่อเซิร์ฟเวอร์ไคลเอนต์อาจรวมส่วนขยายประเภท "server_name" ในไคลเอนต์ (ขยาย) สวัสดี

ในระยะสั้น:

FQDN (ส่วนหนึ่งของโดเมนของ URL) อาจจะส่งในที่ชัดเจนภายในClientHelloแพ็คเก็ตถ้าขยาย SNI ถูกนำมาใช้
ส่วนที่เหลือของ URL ( /path/?some=parameters&go=here) ไม่มีธุรกิจที่อยู่ภายในClientHelloเนื่องจาก URL คำขอเป็นสิ่ง HTTP (OSI Layer 7) ดังนั้นจะไม่แสดงในการจับมือ TLS (Layer 4 หรือ 5) ที่จะมาในภายหลังในGET /path/?some=parameters&go=here HTTP/1.1การร้องขอ HTTP, AFTER ที่เชื่อถือได้ของช่อง TLS ถูกจัดตั้งขึ้น

บทสรุปผู้บริหาร

ชื่อโดเมนอาจถูกส่งแบบชัดเจน (หากใช้ส่วนขยาย SNI ในการจับมือ TLS) แต่ URL (พา ธ และพารามิเตอร์) จะถูกเข้ารหัสเสมอ

มีนาคม 2019 อัพเดท

ขอบคุณcarlin.scott ที่นำสิ่งนี้มา

เพย์โหลดในส่วนขยาย SNI สามารถเข้ารหัสได้ผ่านข้อเสนอ RFC ฉบับร่างนี้ ความสามารถนี้มีอยู่ใน TLS 1.3 เท่านั้น (เป็นตัวเลือกและขึ้นอยู่กับการใช้งานทั้งสองด้าน) และไม่มีความเข้ากันได้แบบย้อนกลับกับ TLS 1.2 และด้านล่าง

CloudFlare กำลังทำอยู่และคุณสามารถอ่านเพิ่มเติมเกี่ยวกับ internals ได้ที่นี่ - ถ้าไก่ต้องมาก่อนไข่คุณจะใส่ไก่ที่ไหน

ในทางปฏิบัติหมายความว่าแทนที่จะส่ง FQDN เป็นข้อความธรรมดา (เช่นรายการจับภาพ Wireshark) ตอนนี้จะถูกเข้ารหัส

หมายเหตุ:ที่อยู่ด้านความเป็นส่วนตัวมากกว่าความปลอดภัยตั้งแต่การค้นหา DNS ย้อนกลับอาจเปิดเผยโฮสต์ปลายทางที่ตั้งใจอยู่แล้ว

— evilSnobu
แหล่งที่มา

37

คำตอบที่สมบูรณ์แบบพร้อมคำอธิบายที่สมบูรณ์จาก A ถึง Z ฉันชอบบทสรุปผู้บริหาร ทำให้วันของฉันเป็นจริง @evilSnobu

— oscaroscar

4

คำตอบที่สมบูรณ์แบบโหวตขึ้น! ยังคงพิจารณาส่วนของไคลเอ็นต์เนื่องจากประวัติเบราว์เซอร์อาจรั่ว อย่างไรก็ตามเกี่ยวกับเลเยอร์การขนส่ง URL- พารามิเตอร์จะถูกเข้ารหัส

— Jens Kreidler

2

คุณอาจต้องการอัปเดตคำตอบนี้ด้วยความจริงที่ว่า TLS 1.3 เข้ารหัสส่วนขยาย SNI และ CDN ที่ใหญ่ที่สุดกำลังทำเช่นนั้น: blog.cloudflare.com/encrypted-sni แน่นอนแพ็คเก็ตดมกลิ่นสามารถค้นหา reverse-dns สำหรับ ที่อยู่ IP ที่คุณกำลังเชื่อมต่อ

— carlin.scott

@evilSnobu แต่ชื่อผู้ใช้: ส่วนรหัสผ่านของชื่อผู้ใช้: password@domain.comถูกเข้ารหัสใช่ไหม ดังนั้นจึงปลอดภัยที่จะส่งผ่านข้อมูลที่สำคัญใน URL โดยใช้ https

— Maksim Shamihulau

1

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

— evilSnobu

159

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

— Zach Scrivena
แหล่งที่มา

21

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

— Steve Jessop

8

@SteveJessop โปรดระบุลิงก์ไปยัง"แฮ็ก Javascript ที่อนุญาตให้เว็บไซต์ที่ไม่เกี่ยวข้องอย่างสมบูรณ์เพื่อทดสอบว่า URL ที่ระบุอยู่ในประวัติของคุณหรือไม่"

— Pacerier

6

@Pacerier: วันที่แฮ็กแน่นอน แต่สิ่งที่ผมได้พูดคุยเกี่ยวกับช่วงเวลาที่สิ่งที่ต้องการstackoverflow.com/questions/2394890/... มันเป็นเรื่องใหญ่ในปี 2010 ที่ปัญหาเหล่านี้กำลังถูกตรวจสอบและการโจมตีได้รับการปรับปรุง แต่ฉันไม่ได้ติดตามมันในขณะนี้

— Steve Jessop

2

@Pacerier: ตัวอย่างเพิ่มเติม: webdevwonders.com/… , webdevwonders.com/ ...

— Steve Jessop

1

คุณสามารถใช้ OpenDNS ด้วยบริการ DNS ที่เข้ารหัส ฉันใช้บน Mac ของฉัน แต่ฉันพบว่ารุ่น Windows ทำงานไม่ถูกต้อง แม้ว่าจะผ่านมาสักพักแล้วดังนั้นมันอาจจะใช้ได้เลย สำหรับ Linux ยังไม่มี opendns.com/about/innovations/dnscrypt

— SPRBRN

101

คำขอและการตอบกลับทั้งหมดถูกเข้ารหัสรวมถึง URL

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

— Peter Štibraný
แหล่งที่มา

1

ความครบถ้วนของคำขอ ชื่อโฮสต์จะถูกส่งในที่ชัดเจน สิ่งอื่นถูกเข้ารหัส

— Sam Sirry

98

ฉันเห็นด้วยกับคำตอบก่อนหน้านี้:

จะชัดเจน:

ด้วย TLS ส่วนแรกของ URL ( https://www.example.com/ ) จะยังคงปรากฏให้เห็นเมื่อสร้างการเชื่อมต่อ ส่วนที่สอง (/ herearemygetparameters / 1/2/3/4) ได้รับการคุ้มครองโดย TLS

อย่างไรก็ตามมีหลายสาเหตุที่คุณไม่ควรใส่พารามิเตอร์ในคำขอ GET

ก่อนอื่นตามที่ผู้อื่นกล่าวถึงแล้ว: - การรั่วไหลผ่านแถบที่อยู่ของเบราว์เซอร์ - การรั่วไหลผ่านประวัติศาสตร์

นอกจากนั้นคุณมีการรั่วไหลของ URL ผ่านผู้อ้างอิง http: ผู้ใช้เห็นไซต์ A บน TLS จากนั้นคลิกลิงก์ไปยังไซต์ B หากทั้งสองไซต์อยู่บน TLS การร้องขอไปยังไซต์ B จะมี URL แบบเต็มจากไซต์ A ใน พารามิเตอร์ referer ของการร้องขอ และผู้ดูแลระบบจากไซต์ B สามารถเรียกดูได้จากไฟล์บันทึกของเซิร์ฟเวอร์ B. )

— โทเบียส
แหล่งที่มา

3

@EJP คุณไม่เข้าใจสิ่งที่ Tobias พูด เขาบอกว่าถ้าคุณคลิกลิงก์ในไซต์ A ที่จะนำคุณไปยังไซต์ B ไซต์ B จะได้รับ URL ผู้อ้างอิง ตัวอย่างเช่นหากคุณอยู่ในsiteA.com?u=username&pw=123123ดังนั้น siteB.com (ซึ่งเชื่อมโยงกับหน้าของ siteA.com) จะได้รับ " siteA.com?u=username&pw=123123 " เป็นการอ้างอิง URL ที่ส่งไปยัง siteB.com ภายในเบราว์เซอร์ HTTPS ถ้านี่เป็นเรื่องจริงมันก็แย่มาก โทเบียสที่แท้จริงนี้หรือไม่

— trusktr

9

@EJP โดเมนสามารถมองเห็นได้เนื่องจากSNIซึ่งเว็บเบราว์เซอร์ที่ทันสมัยทั้งหมดใช้ ดูแผนภาพนี้จาก EFF ซึ่งแสดงให้เห็นว่าทุกคนสามารถเห็นโดเมนของไซต์ที่คุณเยี่ยมชมได้ นี่ไม่เกี่ยวกับการเปิดเผยเบราว์เซอร์ มันเกี่ยวกับสิ่งที่มองเห็นได้จากการดักฟัง

— Buge

10

@trusktr: เบราว์เซอร์ไม่ควรส่งหัวข้อผู้อ้างอิงจากหน้า HTTPS นี่คือส่วนหนึ่งของข้อกำหนดของ HTTP

— Martin Geisler

8

@MartinGeisler คำหลักคือ "ควร" เบราว์เซอร์ไม่สนใจ "ควร" มากนัก (ตรงข้ามกับ "ต้อง") จากการเชื่อมโยงของคุณเอง: "ขอแนะนำให้ผู้ใช้สามารถที่จะเลือกหรือไม่ว่าสนาม Referer จะถูกส่งไปตัวอย่างเช่นลูกค้าเบราว์เซอร์จะมีสวิทช์สลับสำหรับการท่องเปิดเผย / ไม่ระบุชื่อซึ่งตามลำดับจะ. เปิดใช้งาน / ปิดการใช้งานการส่ง อ้างอิงและจากข้อมูล" Ops ซึ่งเป็นสิ่งที่ Chrome ทำ ยกเว้น Chrome รั่วไหลอ้างอิงแม้ว่าคุณจะอยู่ในโหมดไม่ระบุตัวตน

— Pacerier

48

นอกเหนือจากคำตอบที่เป็นประโยชน์จาก Marc Novakowski - URL จะถูกเก็บไว้ในบันทึกของเซิร์ฟเวอร์ (เช่นใน / etc / httpd / logs / ssl_access_log) ดังนั้นหากคุณไม่ต้องการให้เซิร์ฟเวอร์รักษาข้อมูลไว้นาน คำไม่ควรใส่ไว้ใน URL

— Rhodri Cusack
แหล่งที่มา

34

ใช่และไม่.

ส่วนที่อยู่เซิร์ฟเวอร์จะไม่ถูกเข้ารหัสเนื่องจากใช้เพื่อตั้งค่าการเชื่อมต่อ

สิ่งนี้อาจเปลี่ยนแปลงได้ในอนาคตด้วย SNI และ DNS ที่เข้ารหัส แต่ในปี 2018 เทคโนโลยีทั้งสองไม่ได้ถูกใช้งานบ่อย

เส้นทางสตริงแบบสอบถาม ฯลฯ ถูกเข้ารหัส

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

— แท่นสำหรับนักพูดบนถนน
แหล่งที่มา

8

ต้องการ +1 สิ่งนี้ แต่ฉันพบว่า "ใช่และไม่ใช่" ทำให้เข้าใจผิด - คุณควรเปลี่ยนให้ชี้ให้เห็นว่าชื่อเซิร์ฟเวอร์จะได้รับการแก้ไขโดยใช้ DNS โดยไม่มีการเข้ารหัส

— Lawrence Dol

7

ในความเข้าใจของฉัน OP ใช้คำว่า URL อย่างถูกต้อง ฉันคิดว่าคำตอบนี้ทำให้เข้าใจผิดมากขึ้นเนื่องจากไม่ได้สร้างความแตกต่างอย่างชัดเจนระหว่างชื่อโฮสต์ใน URL และชื่อโฮสต์ในการแก้ไข DNS

— Guillaume

4

URL ถูกเข้ารหัส การทำธุรกรรม HTTP ทุกแง่มุมถูกเข้ารหัส ไม่เพียง 'ทุกอย่างอื่น' ระยะเวลา -1

— user207421

4

@EJP แต่การค้นหา DNS ไม่ใช้สิ่งที่เป็นส่วนหนึ่งจุดหนึ่งของ URL เพื่อไปยังบุคคลที่ไม่ใช่ทางด้านเทคนิค URL ทั้งหมดไม่ได้เข้ารหัส บุคคลที่ไม่ใช่ด้านเทคนิคซึ่งใช้ Google.com เพียงเพื่อค้นหาสิ่งที่ไม่ใช่ด้านเทคนิคจะไม่ทราบว่าข้อมูลอยู่ในท้ายที่สุดหรือมีการจัดการอย่างไร โดเมนซึ่งเป็นส่วนหนึ่งของ URL ที่ผู้ใช้เข้าชมนั้นไม่ได้เข้ารหัส 100% เพราะฉันในฐานะผู้โจมตีสามารถดมกลิ่นเว็บไซต์ที่เขากำลังเยี่ยมชม เฉพาะ / พา ธ ของ URL เท่านั้นที่ถูกเข้ารหัสไว้กับคนธรรมดา (โดยไม่สำคัญว่าจะเป็นอย่างไร)

— trusktr

6

@EJP, @ trusktr, @ Lawrence, @ Guillaume พวกคุณทุกคนเข้าใจผิด สิ่งนี้ไม่เกี่ยวกับ DNS SNI " ส่งชื่อโดเมนเสมือนเป็นส่วนหนึ่งของการเจรจา TLS " ดังนั้นแม้ว่าคุณจะไม่ใช้ DNS หรือถ้า DNS ของคุณถูกเข้ารหัสผู้ดมกลิ่นยังสามารถเห็นชื่อโฮสต์ของคำขอของคุณ

— Pacerier

9

บุคคลที่สามที่กำลังตรวจสอบปริมาณการใช้งานอาจสามารถกำหนดหน้าที่เข้าชมโดยตรวจสอบปริมาณข้อมูลของคุณเปรียบเทียบกับปริมาณข้อมูลที่ผู้ใช้รายอื่นมีเมื่อเยี่ยมชมเว็บไซต์ ตัวอย่างเช่นหากมี 2 หน้าในเว็บไซต์เดียวมีขนาดใหญ่กว่าอีกหน้าหนึ่งจากนั้นการเปรียบเทียบขนาดของการถ่ายโอนข้อมูลจะบอกว่าคุณเข้าชมหน้าไหน มีหลายวิธีที่อาจถูกซ่อนจากบุคคลที่สาม แต่ไม่ใช่เซิร์ฟเวอร์หรือพฤติกรรมของเบราว์เซอร์ ดูตัวอย่างกระดาษนี้จาก SciRate, https://scirate.com/arxiv/1403.0297

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

— pbhj
แหล่งที่มา

นั่นจะเป็นไปได้จริงในเว็บไซต์ที่มีขนาดเล็กมากและในกรณีเหล่านั้นธีม / โทน / ลักษณะของไซต์อาจจะยังคงเหมือนเดิมในแต่ละหน้า

— คาเมรอน

5

จากการอ้างอิงที่ฉันให้: "เรานำเสนอการวิเคราะห์การโจมตีมากกว่า 6,000 เว็บเพจซึ่งครอบคลุมการปรับใช้ HTTPS ของเว็บไซต์ที่เป็นผู้นำในอุตสาหกรรม 10 แห่งในด้านต่าง ๆ เช่นการดูแลสุขภาพการเงินบริการทางกฎหมายและวิดีโอสตรีมมิ่งการโจมตีของเราระบุหน้าเว็บแต่ละหน้า เว็บไซต์เดียวกันที่มีความแม่นยำ 89% [... ] " ดูเหมือนว่าข้อสรุปของคุณเกี่ยวกับความเป็นไปได้นั้นผิด

— pbhj

2

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

— Dan Bechard

7

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

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

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

ตัวอย่างหนึ่งของการติดตั้งการตรวจสอบมีการอธิบายโดยด่านที่นี่ อาจมีการตั้งค่า "คาเฟ่อินเทอร์เน็ต" แบบเก่าโดยใช้พีซีที่ให้มาด้วย

— ดอนกิลลิส
แหล่งที่มา

6

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

— JoshBerke
แหล่งที่มา

การโทรจากบุคคลที่สามของคุณนั้นเป็น HTTPS เช่นกัน แต่นี่ไม่ใช่ปัญหาใช่มั้ย

— เลียม

3

มันจะถูกเข้ารหัสด้วยใบรับรองบุคคลที่สามเพื่อให้พวกเขาสามารถดู URL

— JoshBerke

5

ตอนนี้เป็นปี 2019 และได้รับการปล่อยตัว TLS v1.3 ตาม Cloudflare SNI นั้นสามารถเข้ารหัสได้ด้วย TLS v1.3 ดังนั้นฉันบอกตัวเองดีมาก! มาดูกันว่ามันมีลักษณะอย่างไรในแพ็คเก็ต TCP ของ cloudflare.com ดังนั้นฉันจับแพ็คเก็ตจับมือ "ไคลเอนต์สวัสดี" จากการตอบสนองของเซิร์ฟเวอร์ cloudflare โดยใช้ Google Chrome เป็นเบราว์เซอร์ & wireshark เป็นดมกลิ่นแพ็คเก็ต ฉันยังคงสามารถอ่านชื่อเซิร์ฟเวอร์เป็นข้อความธรรมดาภายในแพ็กเก็ต Hello Client

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

ดังนั้นดูเหมือนว่าการเข้ารหัสของ SNI จะต้องมีการนำไปใช้งานเพิ่มเติมเพื่อทำงานร่วมกับ TLSv1.3

บทความต่อไปนี้อธิบายการเข้ารหัสของ SNI ที่จัดทำโดย Cloudflare ซึ่งเป็นส่วนหนึ่งของ TLSv1.3 อย่างไรก็ตาม URL HTTPs ทั้งหมดจาก cloudflare.com อยู่ในข้อความธรรมดาภายในแพ็กเก็ต TCP ภายใต้ TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/ เหมือนพี่น้อง 3]

— Nicolas Guérinet
แหล่งที่มา

"SNI สามารถเข้ารหัสได้" - นั่นคือประเด็นสำคัญ กำลังตรวจสอบcloudflare.com/ssl/encrypted-sniกับ Google Chrome ปัจจุบันว่า "เบราว์เซอร์ของคุณไม่ได้เข้ารหัส SNI เมื่อเยี่ยมชมหน้านี้" มันต้องใช้เวลาสองถึงเต้นจังหวะแทงโก้ ...

— Piskvor ซ้ายอาคาร

Apparently Firefox ปัจจุบันสามารถทำ ESNI ได้ แต่จะปิดใช้งานตามค่าเริ่มต้น: คุณต้องเปิดใช้network.security.esni.enabledงานตั้งค่าnetwork.trr.modeเป็น 2 (ซึ่งปัจจุบันตั้งค่าตัวแก้ไข DoH เป็น CloudFlare) และรีสตาร์ทเบราว์เซอร์ (sic!); จากนั้นจะใช้ ESNI - ซึ่งรองรับโครงสร้างพื้นฐานของโดเมน ดูblog.mozilla.org/security/2018/10/18/…สำหรับรายละเอียด

— Piskvor ออกจากอาคาร

3

ใช่และไม่.

URL จริงถูกเข้ารหัสหมายความว่าบางคนไม่สามารถบอกหน้าเว็บที่แน่นอนในเว็บไซต์ที่คุณเยี่ยมชม อย่างไรก็ตามส่วนหัว TLS มีชื่อโฮสต์ของเซิร์ฟเวอร์ที่คุณกำลังเข้าถึง (เช่น www.quora.com) ที่ไม่ได้เข้ารหัส DNS นั้นแทบไม่เคยเข้ารหัสและจะรั่วไหลชื่อโฮสต์ที่คุณกำลังเข้าถึง การค้นหา DNS นี้มักจะเทียบกับเซิร์ฟเวอร์ของ ISP ของคุณเป็นค่าเริ่มต้นดังนั้นพวกเขาจึงสามารถดูชื่อโฮสต์ของทุกเว็บไซต์ที่คุณเข้าถึงได้โดยการดมกลิ่นคำร้องขอ DNS ของคุณไปยังเซิร์ฟเวอร์ DNS อื่นหรือบันทึกของคุณเอง

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

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

หากคุณกำลังมองหามาตรฐานความเป็นส่วนตัวระดับสูงคุณจะต้องเสริม HTTPS ด้วย VPN ที่เข้ารหัสและ / หรือบริการพร็อกซีที่เข้ารหัสที่เชื่อถือได้ นอกจากนี้คุณยังสามารถดู DNSSEC เพื่อป้องกันการสืบค้น DNS ของคุณ บริการนี้จะต้องเชื่อถือได้เพราะสามารถดำเนินการติดตามแหล่งที่มาและปลายทางของการเข้าชมของคุณได้อย่างง่ายดาย

— Himanshu Patel
แหล่งที่มา

2

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

สำหรับปพลิเคชันมือถือถ้าคุณสามารถควบคุมปลายทั้งสองของแอพลิเคชัน (เซิร์ฟเวอร์และ app) ตราบใดที่คุณใช้ HTTPS คุณกำลังรักษาความปลอดภัย iOS หรือ Android จะตรวจสอบใบรับรองและลดการโจมตี MiM ที่อาจเกิดขึ้น (ซึ่งเป็นจุดอ่อนเดียวในเรื่องนี้) คุณสามารถส่งข้อมูลที่สำคัญผ่านการเชื่อมต่อ HTTPS ว่ามันจะได้รับการเข้ารหัสในระหว่างการขนส่ง เพียงแค่แอปของคุณและเซิร์ฟเวอร์จะรู้พารามิเตอร์ใด ๆ ที่ส่งผ่าน https

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

— Ricardo BRGWeb
แหล่งที่มา

1

นอกจากนี้หากคุณกำลังสร้าง ReSTful API ปัญหาการรั่วไหลของเบราว์เซอร์และ http referer นั้นส่วนใหญ่จะลดลงเนื่องจากไคลเอนต์อาจไม่ใช่เบราว์เซอร์และคุณอาจไม่มีคนคลิกลิงก์

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

— Chris Rutledge
แหล่งที่มา

0

ในขณะที่คุณมีคำตอบที่ดีมากฉันชอบคำอธิบายในเว็บไซต์นี้: https://https.cio.gov/faq/#what-information-does-https-protect

ในระยะสั้น: การใช้ HTTPS ซ่อน:

วิธี HTTP
พารามิเตอร์แบบสอบถาม
ร่างกายโพสต์ (ถ้ามี)
ขอส่วนหัว (รวมคุกกี้)
รหัสสถานะ

— pedrorijo91
แหล่งที่มา

HTTPS URL นั้นเข้ารหัสหรือไม่?

ในระยะสั้น:

บทสรุปผู้บริหาร

มีนาคม 2019 อัพเดท

ส่วนที่อยู่เซิร์ฟเวอร์จะไม่ถูกเข้ารหัสเนื่องจากใช้เพื่อตั้งค่าการเชื่อมต่อ

เส้นทางสตริงแบบสอบถาม ฯลฯ ถูกเข้ารหัส