สวัสดี! เมื่อเร็ว ๆ นี้ ฉันกำลังคิดว่าจะสนุกกับการเรียนระบบเครือข่ายคอมพิวเตอร์โดยใช้โปรโตคอลเครือข่ายจริงในเวอร์ชันที่ใช้งานได้จริงได้อย่างไร
และมันทำให้ฉันสงสัย – ฉันใช้เวอร์ชันของเล่นของ traceroute , TCP และ DNS แล้ว TLS ล่ะ? ฉันสามารถใช้เวอร์ชันของเล่นเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการทำงานได้หรือไม่
ฉันถามใน Twitter ว่ามันจะยากไหม ได้รับ กำลังใจและคำแนะนำว่าควรเริ่มจากตรงไหน ฉันจึงตัดสินใจทำ
มันสนุกจริงๆ และฉันได้เรียนรู้เพิ่มเติมเล็กน้อยเกี่ยวกับความเกี่ยวข้องของการเข้ารหัสที่แท้จริง – ฉันเชื่อ 100% แล้วว่าฉันไม่ควรประดิษฐ์การใช้งาน crypto ของตัวเอง และการเห็นว่า crypto ใน TLS 1.3 ทำงานอย่างไร ก็ยิ่งรู้สึกซาบซึ้งมากขึ้นว่าทำไม ฉันไม่ควร 🙂
เพื่อเป็นการเตือน: ฉันไม่ใช่คนเข้ารหัสจริงๆ ฉันอาจจะพูดสิ่งที่ไม่ถูกต้องเกี่ยวกับการเข้ารหัสในโพสต์นี้ และฉันไม่ทราบประวัติของช่องโหว่ TLS ในอดีตที่แจ้งการออกแบบของ TLS 1.3 เลย
จากทั้งหมดที่กล่าวมา มาเริ่มใช้งานการเข้ารหัสกันเถอะ! รหัสแฮ็กทั้งหมดของฉันอยู่ ใน github
ความเรียบง่าย
ฉันเพียงต้องการทำงานเกี่ยวกับเรื่องนี้เพียงไม่กี่วันเท่านั้น ดังนั้นฉันจึงจำเป็นต้องทำให้เข้าใจง่ายขึ้นอย่างมากเพื่อให้เสร็จได้อย่างรวดเร็ว
ฉันตัดสินใจว่าเป้าหมายของฉันคือดาวน์โหลดหน้าแรกของบล็อกนี้ด้วย TLS ดังนั้นฉันจึงไม่ต้องปรับใช้ TLS ทั่วไปโดยสมบูรณ์ ฉันแค่ต้องเชื่อมต่อกับเว็บไซต์เดียวให้สำเร็จ
โดยเฉพาะอย่างยิ่ง นี่หมายความว่า:
- ฉันสนับสนุนชุดรหัสเดียวเท่านั้น
- ฉันไม่ตรวจสอบใบรับรองของเซิร์ฟเวอร์เลย ฉันแค่เพิกเฉย
- การแยกวิเคราะห์และการจัดรูปแบบข้อความของฉันอาจดูหยาบและเปราะบางมาก เพราะฉันต้องสามารถพูดคุยกับการใช้งาน TLS ที่เฉพาะเจาะจงได้เพียงอย่างเดียว (และเชื่อฉันเถอะ พวกเขาเป็นเช่นนั้น)
ทรัพยากร TLS ที่น่าทึ่ง: tls13.ulfheim.net
โชคดีที่ก่อนเริ่มสิ่งนี้ ฉันจำได้ไม่ชัดว่าเคยเห็นเว็บไซต์ที่อธิบายทุกๆ ไบต์ในการเชื่อมต่อ TLS 1.3 พร้อมตัวอย่างโค้ดโดยละเอียดเพื่อทำซ้ำทุกส่วน googling บางคนเปิดเผยว่ามันคือ The New Illustrated TLS Connection
ฉันไม่สามารถเน้นว่าสิ่งนี้มีประโยชน์เพียงใด ฉันดูมากกว่าร้อยครั้งแล้วดู TLS 1.3 RFC สำหรับสิ่งเล็ก ๆ น้อย ๆ เท่านั้น
พื้นฐานการเข้ารหัสบางอย่าง
ก่อนที่ฉันจะเริ่มทำงานนี้ ความเข้าใจของฉันเกี่ยวกับ TLS คือ:
- ที่จุดเริ่มต้นมีการแลกเปลี่ยนคีย์ Diffie-Hellman บางประเภท
- คุณใช้การแลกเปลี่ยนคีย์เพื่อรับคีย์สมมาตร AES (อย่างไร) และเข้ารหัสการเชื่อมต่อที่เหลือด้วย AES
ถูกต้อง แต่ปรากฏว่ามันซับซ้อนกว่านั้น
โอเค มาเริ่มใช้งาน TLS ของเล่นแฮ็คของฉันกัน หวังว่าจะดำเนินไปโดยไม่ได้บอกว่าคุณไม่ควรใช้รหัสนี้เพื่อสิ่งใดโดยเด็ดขาด
ขั้นตอนที่ 1: กล่าวสวัสดี
อันดับแรก เราต้องส่งข้อความ “สวัสดีลูกค้า” สำหรับจุดประสงค์ของฉัน มีข้อมูลเพียง 4 ชิ้นในนั้น:
- คีย์สาธารณะที่สร้างแบบสุ่ม
- ข้อมูลสุ่ม 32 ไบต์ (“สุ่มไคลเอ็นต์”)
- ชื่อโดเมนที่ฉันต้องการเชื่อมต่อ (
jvns.ca )
- ชุดรหัส/อัลกอริธึมลายเซ็นที่เราต้องการใช้ (ซึ่งฉันเพิ่งคัดลอกมาจาก tls.ulfheim.net) กระบวนการเจรจานี้ค่อนข้างสำคัญโดยทั่วไป แต่ฉันไม่สนใจเพราะฉันสนับสนุนอัลกอริธึมลายเซ็น / ชุดการเข้ารหัสเดียวเท่านั้น
ส่วนที่น่าสนใจที่สุดสำหรับฉันคือส่วนที่ 1 – ฉันจะสร้างกุญแจสาธารณะได้อย่างไร
ฉันสับสนเกี่ยวกับสิ่งนี้อยู่พักหนึ่ง แต่มันจบลงด้วยโค้ดเพียง 2 บรรทัด
privateKey := random(32) publicKey, err := curve25519.X25519(privateKey, curve25519.Basepoint)
คุณสามารถดูโค้ดที่เหลือเพื่อสร้าง ข้อความสวัสดีลูกค้าได้ที่นี่ แต่มันน่าเบื่อมาก มันแค่เล่นซอกันนิดหน่อย
การเข้ารหัสเส้นโค้งวงรีนั้นยอดเยี่ยม
ฉันจะไม่อธิบายเกี่ยวกับการเข้ารหัสเส้นโค้งวงรีที่นี่ แต่ฉันแค่อยากจะบอกว่ามันเจ๋งแค่ไหนที่คุณสามารถ:
- สร้างสตริง 32 ไบต์แบบสุ่มเป็นคีย์ส่วนตัว
- “คูณ” คีย์ส่วนตัวด้วยจุดฐานของเส้นโค้งเพื่อรับกุญแจสาธารณะ (นี่คือ “การคูณ” ของเส้นโค้งวงรีโดยที่
n * P หมายถึง “เพิ่ม P ให้กับตัวเอง n ครั้ง”)
- แค่นั้นแหละ!!
ฉันจะไม่พูดเพิ่มเติมเกี่ยวกับการเข้ารหัสเส้นโค้งวงรีที่นี่ แต่ฉันชอบความง่ายในการใช้งาน – ดูเหมือนตรงไปตรงมากว่า RSA มากซึ่งคีย์ส่วนตัวของคุณต้องเป็นตัวเลขเฉพาะ
ฉันไม่รู้ว่า “คุณสามารถสร้างสตริงขนาด 32 ไบต์ใดๆ เป็นไพรเวตคีย์” ได้หรือไม่สำหรับเส้นโค้งวงรีทั้งหมดหรือสำหรับเส้นโค้งวงรีเฉพาะนี้ ( Curve25519 )
ขั้นตอนที่ 2: แยกวิเคราะห์เซิร์ฟเวอร์ hello
ถัดไปเซิร์ฟเวอร์กล่าวสวัสดี มันน่าเบื่อมาก โดยพื้นฐานแล้วเราแค่ต้องแยกวิเคราะห์เพื่อรับกุญแจสาธารณะของเซิร์ฟเวอร์ซึ่งมีขนาด 32 ไบต์ นี่คือรหัสแม้ว่า
ขั้นตอนที่ 3: คำนวณคีย์เพื่อเข้ารหัสการจับมือกัน
ตอนนี้เรามีคีย์สาธารณะของเซิร์ฟเวอร์แล้ว และเราได้ส่งคีย์สาธารณะของเราไปยังเซิร์ฟเวอร์แล้ว เราสามารถเริ่มคำนวณคีย์ที่เราจะใช้ในการเข้ารหัสข้อมูลได้จริง
ฉันรู้สึกประหลาดใจที่รู้ว่ามีคีย์สมมาตรอย่างน้อย 4 คีย์ที่เกี่ยวข้องใน TLS:
- คีย์การจับมือลูกค้า/iv (สำหรับข้อมูลที่ลูกค้าส่งในการจับมือกัน)
- คีย์การจับมือเซิร์ฟเวอร์/iv (สำหรับข้อมูลที่เซิร์ฟเวอร์ส่งในการจับมือกัน)
- รหัสแอปพลิเคชันไคลเอ็นต์/iv (สำหรับข้อมูลที่เหลือที่ไคลเอ็นต์ส่ง)
- รหัสแอปพลิเคชันเซิร์ฟเวอร์/iv (สำหรับข้อมูลที่เหลือที่เซิร์ฟเวอร์ส่ง)
- ฉันคิดว่าเป็นอีกกุญแจสำคัญสำหรับการเริ่มเซสชันใหม่ แต่ฉันไม่ได้ใช้สิ่งนั้น
เราเริ่มต้นด้วยการรวมคีย์ส่วนตัวของเซิร์ฟเวอร์และคีย์สาธารณะของเราเข้าด้วยกันเพื่อรับความลับที่ใช้ร่วมกัน สิ่งนี้เรียกว่า “elliptic curve diffie hellman” หรือ ECDH และค่อนข้างง่าย: “คูณ” คีย์ส่วนตัวของเซิร์ฟเวอร์ด้วยคีย์สาธารณะของเรา:
sharedSecret, err := curve25519.X25519(session.Keys.Private, session.ServerHello.PublicKey)
ซึ่งจะทำให้เรามีคีย์ลับขนาด 32 ไบต์ที่ทั้งไคลเอ็นต์และเซิร์ฟเวอร์มี เย้!
แต่เราต้องการ 96 ไบต์ (16 + 12) * 4 คีย์ทั้งหมด นั่นมากกว่า 32 ไบต์!
เวลาสำหรับการได้มาที่สำคัญ
เห็นได้ชัดว่าวิธีที่คุณเปลี่ยนคีย์ขนาดเล็กเป็นคีย์เพิ่มเติมเรียกว่า “การสร้างคีย์” และ TLS 1.3 ใช้อัลกอริธึมที่เรียกว่า “HKDF” ในการดำเนินการนี้ ฉันไม่เข้าใจสิ่งนี้จริง ๆ แต่นี่คือสิ่งที่รหัสของฉันต้องทำ
ดูเหมือนว่าจะเกี่ยวข้องกับการเรียก hkdf.Expand และ hkdf.Extract กันหลายครั้ง
func (session *Session) MakeHandshakeKeys() { zeros := make([]byte, 32) psk := make([]byte, 32) // ok so far if err != nil { panic(err) } earlySecret := hkdf.Extract(sha256.New, psk, zeros) // TODO: psk might be wrong derivedSecret := deriveSecret(earlySecret, "derived", []byte{}) session.Keys.HandshakeSecret = hkdf.Extract(sha256.New, sharedSecret, derivedSecret) handshakeMessages := concatenate(session.Messages.ClientHello.Contents(), session.Messages.ServerHello.Contents()) cHsSecret := deriveSecret(session.Keys.HandshakeSecret, "c hs traffic", handshakeMessages) session.Keys.ClientHandshakeSecret = cHsSecret session.Keys.ClientHandshakeKey = hkdfExpandLabel(cHsSecret, "key", []byte{}, 16) session.Keys.ClientHandshakeIV = hkdfExpandLabel(cHsSecret, "iv", []byte{}, 12) sHsSecret := deriveSecret(session.Keys.HandshakeSecret, "s hs traffic", handshakeMessages) session.Keys.ServerHandshakeKey = hkdfExpandLabel(sHsSecret, "key", []byte{}, 16) session.Keys.ServerHandshakeIV = hkdfExpandLabel(sHsSecret, "iv", []byte{}, 12) }
การทำงานนี้ค่อนข้างน่ารำคาญเพราะฉันเอาแต่โต้แย้งเรื่องต่างๆ ที่ไม่ถูกต้อง เหตุผลเดียวที่ฉันจัดการได้ก็เพราะ https://tls13.ulfheim.net มีอินพุตและเอาต์พุตตัวอย่างจำนวนมากและโค้ดตัวอย่าง ดังนั้นฉันจึงสามารถเขียนการทดสอบหน่วยและตรวจสอบโค้ดของฉันกับตัวอย่างการใช้งานไซต์
อย่างไรก็ตาม ในที่สุดฉันก็ได้คีย์ทั้งหมดของฉันแล้ว และถึงเวลาเริ่มถอดรหัสแล้ว!
นอกเหนือจาก IVs
สำหรับแต่ละคีย์จะมี “IV” ซึ่งย่อมาจาก “initialization vector” แนวคิดน่าจะเป็นการใช้เวกเตอร์การเริ่มต้นที่แตกต่างกันสำหรับทุกข้อความที่เราเข้ารหัส/ถอดรหัส สำหรับ More Security ™
ในการใช้งานนี้ วิธีที่เราได้รับ IV ที่แตกต่างกันสำหรับแต่ละข้อความคือการ xoring IV ด้วยจำนวนข้อความที่ส่ง/รับจนถึงตอนนี้
ขั้นตอนที่ 4: เขียนรหัสถอดรหัส
ตอนนี้เรามีคีย์และ IV เหล่านี้แล้ว เราก็สามารถเขียนฟังก์ชัน decrypt ได้
ฉันคิดว่า TLS เพิ่งใช้ AES แต่เห็นได้ชัดว่ามันใช้ “การเข้ารหัสการตรวจสอบสิทธิ์” ที่ด้านบนของ AES ที่ฉันไม่เคยได้ยินมาก่อน
คำอธิบายบทความวิกิพีเดียของการเข้ารหัสที่พิสูจน์ตัวตนนั้นค่อนข้างชัดเจน:
… การเข้ารหัสที่รับรองความถูกต้องสามารถให้การรักษาความปลอดภัยจากการโจมตีแบบเข้ารหัสที่ เลือก ได้ ในการโจมตีเหล่านี้ ฝ่ายตรงข้ามพยายามที่จะได้เปรียบกับระบบการเข้ารหัสลับ (เช่น ข้อมูลเกี่ยวกับคีย์ถอดรหัสลับ) โดยส่ง ciphertexts ที่เลือกอย่างระมัดระวังไปยัง “พยากรณ์การถอดรหัส” และวิเคราะห์ผลลัพธ์ที่ถอดรหัสลับ รูปแบบการเข้ารหัสที่รับรองความถูกต้องสามารถรับรู้ข้อความเข้ารหัสที่สร้างขึ้นอย่างไม่เหมาะสมและปฏิเสธที่จะถอดรหัส ซึ่งจะป้องกันไม่ให้ผู้โจมตีร้องขอการถอดรหัสของข้อความเข้ารหัสใดๆ เว้นแต่จะถูกสร้างขึ้นอย่างถูกต้องโดยใช้อัลกอริธึมการเข้ารหัส
สิ่งนี้สมเหตุสมผลสำหรับฉันเพราะฉันได้ท้าทาย cryptopals บางส่วนและมีการโจมตีแบบนี้ใน cryptopals ชุดที่ 2 (ฉันไม่รู้ว่าเป็นสิ่งเดียวกันหรือเปล่า)
อย่างไรก็ตาม นี่คือโค้ดบางส่วนที่ใช้การเข้ารหัสที่รับรองความถูกต้องตามที่ TLS 1.3 ระบุ ฉันคิดว่า GCM เป็นอัลกอริธึมการเข้ารหัสที่รับรองความถูกต้อง
func decrypt(key, iv, wrapper []byte) []byte { block, err := aes.NewCipher(key) if err != nil { panic(err.Error()) } aesgcm, err := cipher.NewGCM(block) if err != nil { panic(err.Error()) } additional := wrapper[:5] ciphertext := wrapper[5:] plaintext, err := aesgcm.Open(nil, iv, ciphertext, additional) if err != nil { panic(err.Error()) } return plaintext }
ขั้นตอนที่ 5: ถอดรหัสการจับมือเซิร์ฟเวอร์
ถัดไปเซิร์ฟเวอร์ส่งข้อมูลการจับมือกันเพิ่มเติม ซึ่งมีใบรับรองและสิ่งอื่น ๆ
นี่คือรหัสของฉันสำหรับการถอดรหัสการจับมือ โดยพื้นฐานแล้วมันเพียงอ่านข้อมูลที่เข้ารหัสจากเครือข่าย ถอดรหัส และบันทึก
record := readRecord(session.Conn) if record.Type() != 0x17 { panic("expected wrapper") } session.Messages.ServerHandshake = decrypt(session.Keys.ServerHandshakeKey, session.Keys.ServerHandshakeIV, record)
คุณอาจสังเกตเห็นว่าเราไม่ได้ แยกวิเคราะห์ ข้อมูลนี้เลย – นั่นเป็นเพราะเราไม่ต้องการเนื้อหา เนื่องจากเราไม่ได้ตรวจสอบใบรับรองของเซิร์ฟเวอร์
เราต้องการมันสำหรับขั้นตอนต่อไป
ขั้นตอนที่ 6: รับคีย์เพิ่มเติม
เราใช้แฮชของข้อมูลแฮนด์เชค SHA256 ที่เราเพิ่งได้รับจากเซิร์ฟเวอร์เพื่อสร้างคีย์ที่สมมาตรยิ่งขึ้น นี่เกือบจะเป็นขั้นตอนสุดท้ายแล้ว!
ซึ่งเกือบจะเหมือนกันทุกประการกับรหัสที่มาของคีย์ก่อนหน้านี้ แต่ฉันรวมไว้เพราะฉันรู้สึกประหลาดใจที่ต้องทำงานมากเพียงใดเพื่อสร้างคีย์เหล่านี้ทั้งหมด
func (session *Session) MakeApplicationKeys() { handshakeMessages := concatenate( session.Messages.ClientHello.Contents(), session.Messages.ServerHello.Contents(), session.Messages.ServerHandshake.Contents()) zeros := make([]byte, 32) derivedSecret := deriveSecret(session.Keys.HandshakeSecret, "derived", []byte{}) masterSecret := hkdf.Extract(sha256.New, zeros, derivedSecret) cApSecret := deriveSecret(masterSecret, "c ap traffic", handshakeMessages) session.Keys.ClientApplicationKey = hkdfExpandLabel(cApSecret, "key", []byte{}, 16) session.Keys.ClientApplicationIV = hkdfExpandLabel(cApSecret, "iv", []byte{}, 12) sApSecret := deriveSecret(masterSecret, "s ap traffic", handshakeMessages) session.Keys.ServerApplicationKey = hkdfExpandLabel(sApSecret, "key", []byte{}, 16) session.Keys.ServerApplicationIV = hkdfExpandLabel(sApSecret, "iv", []byte{}, 12) }
ขั้นตอนที่ 7: เสร็จสิ้นการจับมือ
ต่อไป เราต้องส่งข้อความ “การจับมือเสร็จสิ้น” ไปยังเซิร์ฟเวอร์เพื่อตรวจสอบว่าทุกอย่างเสร็จสิ้น รหัสนั้นอยู่ ที่นี่
และตอนนี้เราจับมือกันเสร็จแล้ว! นั่นเป็นส่วนที่ยาก การส่งและรับข้อมูลค่อนข้างง่าย
ขั้นตอนที่ 8: ทำการร้องขอ HTTP
ฉันเขียนฟังก์ชัน SendData ที่เข้ารหัสและส่งข้อมูลโดยใช้คีย์ของเรา คราวนี้เราใช้ปุ่ม “application” ไม่ใช่ปุ่ม handshake ทำให้การร้องขอ HTTP ค่อนข้างง่าย:
req := fmt.Sprintf("GET / HTTP/1.1\r\nHost: %s\r\n\r\n", domain) session.SendData([]byte(req))
ขั้นตอนที่ 9: เราสามารถถอดรหัสการตอบกลับได้จริง !!!
ถึงเวลาที่ฉันรอคอย — จริง ๆ แล้วถอดรหัสการตอบกลับจากเซิร์ฟเวอร์!!! แต่ที่นี่ฉันต้องเรียนรู้อย่างอื่นเกี่ยวกับ TLS
ข้อมูล TLS มาในบล็อก
ก่อนหน้านี้ฉันคิดว่าเมื่อคุณสร้างการเชื่อมต่อแล้ว ข้อมูล TLS ที่เข้ารหัสนั้นเป็นเพียงสตรีม แต่นั่นไม่ใช่วิธีการทำงาน – แทนที่จะส่งเป็นบล็อก เช่น คุณจะได้อันนึงประมาณ 1,400 ไบต์เพื่อถอดรหัส แล้วก็อีกอัน แล้วก็อีกอันหนึ่ง
ฉันไม่แน่ใจว่าทำไมบล็อกถึงมีขนาดเท่ากัน (บางทีก็เพื่อให้แต่ละบล็อกพอดีในแพ็กเก็ต TCP ???) แต่ในทางทฤษฎี ฉันคิดว่าพวกมันอาจมีขนาดสูงสุด 65535 ไบต์ เนื่องจากฟิลด์ขนาดของพวกเขาคือ 2 ไบต์ บล็อกที่ฉันได้รับคือแต่ละบล็อก 1386 ไบต์
ทุกครั้งที่เราได้รับบล็อก เราต้อง:
- คำนวณ IV ใหม่เป็น
old_iv xor num_records_received
- ถอดรหัสโดยใช้คีย์และ IV . ใหม่
- เพิ่มจำนวนบันทึกที่ได้รับ
นี่คือหน้าตาของฟังก์ชัน ReceiveData() ที่ฉันเขียน
ส่วนที่น่าสนใจที่สุดคือ iv[11] ^= session.RecordsReceived – นั่นคือส่วนที่ปรับ IV สำหรับแต่ละบล็อก
func (session *Session) ReceiveData() []byte { record := readRecord(session.Conn) iv := make([]byte, 12) copy(iv, session.Keys.ServerApplicationIV) iv[11] ^= session.RecordsReceived plaintext := decrypt(session.Keys.ServerApplicationKey, iv, record) session.RecordsReceived += 1 return plaintext }
iv[11] นี้ถือว่ามีน้อยกว่า 255 บล็อกซึ่งเห็นได้ชัดว่าไม่เป็นความจริงใน TLS ทั่วไป แต่ฉันขี้เกียจและดาวน์โหลดหน้าแรกของบล็อกฉันต้องการเพียง 82 บล็อก
เราต้องทำสิ่งนี้เมื่อเราส่งข้อมูลด้วย แต่ฉันไม่ได้ใช้งานเพราะเราส่งเพียง 1 แพ็กเก็ต
ปัญหา: รับทั้งบล็อกของข้อมูล tLS
ฉันพบปัญหาหนึ่งกับ TCP ซึ่งบางครั้งฉันพยายามอ่านบล็อกข้อมูล TLS (~1386 ไบต์) แต่ฉันจะไม่เข้าใจทั้งหมด ฉันเดาว่าบล็อก TLS สามารถแบ่งออกเป็นหลายแพ็กเก็ต TCP
ฉันแก้ไขปัญหานี้ด้วยวิธีที่โง่มาก โดยเพียงแค่สำรวจการเชื่อมต่อ TCP แบบวนซ้ำจนกว่าจะให้ข้อมูลที่ฉันต้องการ นี่คือรหัสของฉันที่จะทำ:
func read(length int, reader io.Reader) []byte { var buf []byte for len(buf) != length { buf = append(buf, readUpto(length-len(buf), reader)...) } return buf }
ฉันถือว่าการนำ TLS ไปใช้จริงจะใช้เธรดพูลหรือ coroutines หรือบางอย่างเพื่อจัดการสิ่งนี้
ขั้นตอนที่ 10: รู้ว่าเมื่อเราทำเสร็จแล้ว
เมื่อการตอบสนอง HTTP เสร็จสิ้น เราได้รับไบต์เหล่านี้: []byte{48, 13, 10, 13, 10, 23} ฉันไม่รู้ว่าสิ่งนี้หมายความว่าอย่างไร แต่ดูเหมือนว่าจะส่งสัญญาณการสิ้นสุดการเชื่อมต่อ
นี่คือรหัสที่จะได้รับการตอบสนอง HTTP โดยพื้นฐานแล้วเราแค่วนซ้ำจนกว่าเราจะเห็นไบต์เหล่านั้นแล้วเราก็หยุด
func (session *Session) ReceiveHTTPResponse() []byte { var response []byte for { pt := session.ReceiveData() if string(pt) == string([]byte{48, 13, 10, 13, 10, 23}) { break } response = append(response, pt...) } return response }
แค่นั้นแหละ!
ในที่สุด ฉันรันโปรแกรมและดาวน์โหลดหน้าแรกของบล็อกของฉัน! มันได้ผล! ผลลัพธ์จะมีลักษณะดังนี้:
$ go build; ./tiny-tls HTTP/1.1 200 OK Date: Wed, 23 Mar 2022 19:37:47 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive ... lots more headers and HTML follow...
โอเค ผลลัพธ์เป็นแบบต่อต้านไคลแมกซ์ มันเหมือนกับสิ่งที่คุณเห็นถ้าคุณรัน curl -i https://jvns.ca ยกเว้นว่าไม่มีการจัดรูปแบบ แต่ฉันรู้สึกตื่นเต้นมากเมื่อฉันเห็นมัน
ตัวบล็อคมันแปลกๆ
ฉันพบว่ามันค่อนข้างแปลกที่ข้อมูล TLS ถูกส่ง/รับเป็นบล็อค ฉันคิดว่ามันสมเหตุสมผลจากมุมมองของการเข้ารหัส (เพราะคุณต้องการเปลี่ยน IV ของคุณบ่อยๆหรืออย่างอื่น?)
แต่จากมุมมองของเครือข่าย มันรู้สึกแปลกๆ เล็กน้อย เช่นเดียวกับ TCP ถูกสร้างขึ้นบนระบบแพ็คเก็ต จากนั้นด้วย TLS คุณจะมีระบบแพ็คเก็ตอื่นที่ด้านบนของ TCP
บางทีหนึ่งในแรงจูงใจสำหรับ QUIC คือการออกแบบโปรโตคอลเครือข่ายที่มี TLS เป็นพลเมืองชั้นหนึ่งมากกว่า ดังนั้นคุณไม่มีแพ็กเก็ต/สตรีม/แพ็กเก็ตแปลก ๆ นี้ใช่ไหม
บางสิ่งที่ฉันได้เรียนรู้
มันสนุกจริงๆ! ฉันได้เรียนรู้ว่า
- เส้นโค้งวงรี diffie-hellman นั้นเจ๋งมากและอย่างน้อยกับ Curve25519 คุณสามารถใช้สตริง 32 ไบต์ใดก็ได้เป็นคีย์ส่วนตัว
- มีคีย์สมมาตรที่แตกต่างกันมากมายที่เกี่ยวข้องกับ TLS และกระบวนการได้มาซึ่งคีย์นั้นค่อนข้างซับซ้อน
- TLS ใช้ AES พร้อมอัลกอริธึม “การเข้ารหัสที่ตรวจสอบความถูกต้อง” พิเศษอยู่ด้านบน
- ข้อมูล TLS ถูกส่ง/รับเป็นกลุ่มของบล็อก ไม่ใช่เป็นสตรีม
ฉันจะไม่แสร้งทำเป็นว่าเข้าใจเหตุผลทั้งหมด TLS ที่ออกแบบมาด้วยวิธีนี้ แต่มันเป็นวิธีที่สนุกที่จะใช้เวลาสองสามวัน ฉันรู้สึกมีข้อมูลมากขึ้น และฉันคิดว่ามันจะง่ายขึ้นสำหรับฉันที่จะเข้าใจสิ่งที่ฉัน อ่านเกี่ยวกับ TLS ในอนาคต
