เมื่อส่งข้อมูลผ่าน HTTPS ฉันรู้ว่าเนื้อหานั้นได้รับการเข้ารหัส แต่ฉันได้ยินคำตอบที่หลากหลายเกี่ยวกับว่าส่วนหัวได้รับการเข้ารหัสหรือมีการเข้ารหัสส่วนหัวเท่าใด
เท่าใดของ HTTPS ส่วนหัวมีการเข้ารหัส?
รวมถึง URL คำขอ GET / POST, คุกกี้, ฯลฯ
เมื่อส่งข้อมูลผ่าน HTTPS ฉันรู้ว่าเนื้อหานั้นได้รับการเข้ารหัส แต่ฉันได้ยินคำตอบที่หลากหลายเกี่ยวกับว่าส่วนหัวได้รับการเข้ารหัสหรือมีการเข้ารหัสส่วนหัวเท่าใด
เท่าใดของ HTTPS ส่วนหัวมีการเข้ารหัส?
รวมถึง URL คำขอ GET / POST, คุกกี้, ฯลฯ
คำตอบ:
ล็อตทั้งหมดถูกเข้ารหัส† - ส่วนหัวทั้งหมด นั่นเป็นสาเหตุที่ SSL บน vhosts ทำงานได้ไม่ดีนัก - คุณต้องใช้ที่อยู่ IP เฉพาะเนื่องจากส่วนหัวของโฮสต์ถูกเข้ารหัส
†การระบุชื่อ Server (SNI) หมายถึงมาตรฐานที่ชื่อโฮสต์อาจไม่ได้รับการเข้ารหัสหากคุณกำลังใช้ TLS นอกจากนี้ไม่ว่าคุณจะใช้ SNI หรือไม่ส่วนหัว TCP และ IP จะไม่ถูกเข้ารหัส (ถ้าเป็นเช่นนั้นแพ็คเก็ตของคุณจะไม่สามารถกำหนดเส้นทางได้)
ส่วนหัวได้รับการเข้ารหัสทั้งหมด ข้อมูลที่ผ่านเครือข่าย 'ชัดเจน' เท่านั้นที่เกี่ยวข้องกับการตั้งค่า SSL และการแลกเปลี่ยนคีย์ D / H การแลกเปลี่ยนนี้ได้รับการออกแบบมาอย่างระมัดระวังไม่ให้ข้อมูลที่เป็นประโยชน์ใด ๆ กับผู้ดักฟังและเมื่อเกิดขึ้นแล้วข้อมูลทั้งหมดจะถูกเข้ารหัส
คำตอบใหม่สำหรับคำถามเก่าขอโทษ ฉันคิดว่าฉันจะเพิ่ม $ .02 ของฉัน
OP ถามว่ามีการเข้ารหัสส่วนหัวหรือไม่
อยู่ระหว่างการขนส่ง
พวกเขาไม่: เมื่อไม่ได้อยู่ในระหว่างการขนส่ง
ดังนั้น URL ของเบราว์เซอร์ของคุณ (และชื่อในบางกรณี) สามารถแสดงการสืบค้น (ซึ่งมักจะมีรายละเอียดที่ละเอียดอ่อนที่สุด) และรายละเอียดบางอย่างในส่วนหัว เบราว์เซอร์รู้ข้อมูลส่วนหัว (ประเภทเนื้อหา, unicode, ฯลฯ ); และประวัติเบราว์เซอร์การจัดการรหัสผ่านรายการโปรด / ที่คั่นหน้าและหน้าแคชทั้งหมดจะมีการสอบถาม บันทึกเซิร์ฟเวอร์บนปลายทางระยะไกลยังสามารถมีการสอบถามและรายละเอียดเนื้อหาบางส่วน
นอกจากนี้ URL ยังไม่ปลอดภัยเสมอไป: โดเมนโปรโตคอลและพอร์ตจะปรากฏขึ้นมิฉะนั้นเราเตอร์จะไม่ทราบว่าจะส่งคำขอของคุณไปที่ใด
นอกจากนี้หากคุณมีพร็อกซี HTTP เซิร์ฟเวอร์พร็อกซีจะทราบที่อยู่โดยปกติแล้วพวกเขาจะไม่รู้การสืบค้นแบบเต็ม
ดังนั้นหากข้อมูลมีการเคลื่อนไหวข้อมูลจะถูกป้องกันโดยทั่วไป ถ้ามันไม่ได้อยู่ในระหว่างการขนส่งมันจะไม่ถูกเข้ารหัส
ไม่ใช่เพื่อเลือกจาก nit แต่ข้อมูลในตอนท้ายจะถูกถอดรหัสเช่นกันและสามารถแยกวิเคราะห์อ่านบันทึกส่งต่อหรือทิ้งตามความประสงค์ และมัลแวร์ในตอนท้ายสามารถถ่ายภาพข้อมูลที่ป้อน (หรือออก) โปรโตคอล SSL เช่น (ไม่ดี) Javascript ในหน้าภายใน HTTPS ซึ่งสามารถโทรผ่าน http (หรือ https) เพื่อเข้าสู่เว็บไซต์ (ตั้งแต่เข้าถึง harddrive ในเครื่อง) มักถูก จำกัด และไม่มีประโยชน์)
นอกจากนี้คุกกี้จะไม่ถูกเข้ารหัสภายใต้โปรโตคอล HTTPS นักพัฒนาที่ต้องการจัดเก็บข้อมูลที่สำคัญในคุกกี้ (หรือที่อื่น ๆ สำหรับเรื่องนั้น) จำเป็นต้องใช้กลไกการเข้ารหัสของตนเอง
เบราว์เซอร์ที่ทันสมัยส่วนใหญ่จะไม่แคชหน้า HTTPS แต่ความจริงนั้นไม่ได้ถูกกำหนดโดยโปรโตคอล HTTPS มันขึ้นอยู่กับผู้พัฒนาเบราว์เซอร์ทั้งหมดเพื่อให้แน่ใจว่าจะไม่แคชเพจที่ได้รับผ่าน HTTPS
ดังนั้นหากคุณกังวลเกี่ยวกับการดมแพ็คเก็ตคุณอาจไม่เป็นไร แต่ถ้าคุณกังวลเกี่ยวกับมัลแวร์หรือบางคนที่แอบดูประวัติบุ๊กมาร์กคุกกี้หรือแคชคุณยังไม่ได้อยู่ในน้ำ
HTTP เวอร์ชัน 1.1 เพิ่มวิธี HTTP พิเศษ CONNECT - ตั้งใจสร้างอุโมงค์ SSL รวมถึงการจับมือโปรโตคอลที่จำเป็นและการตั้งค่าการเข้ารหัสลับ
คำขอปกติหลังจากนั้นทั้งหมดได้รับการห่อในอุโมงค์ SSL รวมส่วนหัวและร่างกาย
ด้วย SSL การเข้ารหัสอยู่ในระดับการขนส่งดังนั้นจึงเกิดขึ้นก่อนที่จะส่งคำขอ
ดังนั้นทุกอย่างในคำขอจะถูกเข้ารหัส
HTTPS (HTTP ผ่าน SSL) ส่งเนื้อหา HTTP ทั้งหมดผ่านทางช่องสัญญาณ SSL ดังนั้นเนื้อหาและส่วนหัว HTTP จะถูกเข้ารหัสเช่นกัน
ใช่ส่วนหัวได้รับการเข้ารหัส มันเขียนที่นี่
ทุกอย่างในข้อความ HTTPS ถูกเข้ารหัสรวมถึงส่วนหัวและโหลดคำขอ / ตอบกลับ
URL นั้นยังถูกเข้ารหัสคุณมี IP, พอร์ตและถ้า SNI ชื่อโฮสต์ที่ไม่ได้เข้ารหัสเท่านั้น