Tags:
Node Thumbnail

บั๊ก Heartbleed ที่ถูกค้นพบเมื่อไม่กี่วันก่อน ส่งผลสะเทือนไปทั่วโลกไอที เหตุเพราะตัวซอฟต์แวร์ OpenSSL นั้นถูกใช้อย่างกว้างขวางในฐานะซอฟต์แวร์พื้นฐานสำหรับการเข้ารหัส SSL/TLS เพื่อส่งข้อมูลแบบ HTTPS, VPN และทราฟฟิกเข้ารหัสแบบอื่นๆ

การค้นพบช่องโหว่ Heartbleed ถือเป็นการ "เจาะที่หัวใจ" ทำลายความน่าเชื่อถือของการส่งข้อมูลผ่าน SSL/TLS ลงอย่างมาก (ตามสัดส่วนการใช้ OpenSSL) เพราะการเข้ารหัสที่เรา "เชื่อว่าปลอดภัย" นั้นกลับไม่ปลอดภัยอย่างที่เคยคิดกันไว้

บทความนี้จะอธิบายลักษณะของ Heartbleed โดยพื้นฐาน เพื่อให้ผู้อ่าน Blognone เข้าใจมากขึ้นว่ามันเกิดอะไรขึ้นกันแน่นะครับ

พื้นฐานของการเข้ารหัส (Encryption)

อย่างแรกเลยต้องเข้าใจพื้นฐานของการเข้ารหัสข้อมูลหรือ encryption เสียก่อน การเข้ารหัสในปัจจุบันมักใช้รูปแบบ "กุญแจคู่อสมมาตร" คือสุ่มสร้างกุญแจ (key) ออกมาสองตัวพร้อมกัน (แต่กุญแจไม่เหมือนกัน = อสมมาตร) คือ private key และ public key

กุญแจสาธารณะ (public key) จะถูกส่งออกไปในที่สาธารณะ เช่น อินเทอร์เน็ต (ในมิติของความปลอดภัยคือ untrusted space) ส่วนกุญแจส่วนตัว (private key) จะถูกเก็บไว้ในเครื่องของผู้ใช้งานเท่านั้น (มองว่าเป็น trusted หรือ safe space)

เมื่อ A ต้องการส่งข้อมูลลับให้ B ภายใต้สถาปัตยกรรมการเข้ารหัสแบบนี้ A จะนำ public key ของ B (ที่อยู่บนอินเทอร์เน็ต) มาผสมกับตัว "ข้อมูล" (data) ที่ต้องการส่ง เพื่อไม่ให้ใครคนอื่นอ่านได้ยกเว้นแต่ B ที่มีกุญแจคู่กันคือ private key ที่เก็บอยู่กับตัวของ B เท่านั้น

ภาพประกอบจาก Microsoft/MSDN

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

ผู้สนใจสามารถอ่านรายละเอียดได้จากบทความเก่า Asymmetric Cryptography: แตกต่างแต่เข้าใจกัน นะครับ

การทำงานของ SSL/TLS

การทำงานของ SSL/TLS อิงอยู่บนแนวคิดของการเข้ารหัสด้วยกุญแจคู่อสมมาตร แต่เพิ่มแนวคิดเรื่อง "ใบรับรอง" (certificate) ขึ้นมาเพื่อยืนยันตัวตนของผู้รับหรือผู้ส่งข้อมูลอีกชั้นหนึ่ง

กระบวนการออกใบรับรองจำเป็นต้องมี "คนกลาง" เพื่อมายืนยันตัวตน ซึ่งคนกลางคนนี้จะถูกเรียกว่า หน่วยงานออกใบรับรอง (Certification Authority หรือ CA) ส่วนกระบวนการทั้งหมดตั้งแต่ต้นน้ำยันปลายน้ำจะเรียกรวมๆ ว่า public-key infrastructure หรือ PKI

เพื่อให้เข้าใจง่ายๆ ลองดูวิดีโอแนะนำการทำงานเบื้องต้นของ SSL กันก่อนครับ

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

ปัญหา Heartbleed

ตามมาตรฐาน SSL/TLS จะมีตัวเลือกหนึ่งที่ชื่อว่า heartbeat (แปลตรงตัวคือ "หัวใจเต้น") เพื่อให้คอมพิวเตอร์ฝั่งใดฝั่งหนึ่งส่งข้อความสั้นๆ ไปยังอีกคอมพิวเตอร์ฝั่งหนึ่งเพื่อเช็คว่าอีกฝั่งยังออนไลน์อยู่

ปัญหาของ OpenSSL ที่เราเรียกกันว่า Heartbleed (ล้อตามชื่อ heartbeat) คือ OpenSSL ดัน "พลาด" เปิดโอกาสให้คอมพิวเตอร์ฝั่งหนึ่งสามารถส่งข้อความในฟอร์แมตพิเศษ เมื่ออีกฝั่งหนึ่งได้รับข้อความนี้ก็จะส่งข้อมูล (ที่อยู่ในหน่วยความจำ) แถมกลับไปให้ด้วย

ข้อมูลแถมที่ว่านี้จึง "มีความเป็นไปได้" ที่จะเป็น private key ที่อยู่ในเครื่องปลายทางครับ

เพื่อให้เข้าใจง่ายลองดูการ์ตูนของ xkcd ที่อธิบายเรื่องนี้ได้ดีมาก

alt="xkcd heartbleed"

ผลกระทบของ Heartbleed

บั๊ก Heartbleed ถูกแก้ไขใน OpenSSL เวอร์ชันล่าสุดเรียบร้อยแล้ว แก้ง่ายมากแค่อัพเวอร์ชันหรือลงแพตช์ก็หาย

แต่ประเด็นคือไม่มีใครทราบว่า private key ที่ถูกส่งผ่าน OpenSSL มาตั้งแต่ปี 2012 ถูกเจาะผ่านบั๊ก Heartbleed นั้นมีจำนวนเท่าไร และมีเว็บไซต์ไหนที่โดนเจาะบ้าง

ในทางทฤษฎี ผลสะเทือนของ Heartbleed กว้างมาก แต่ในทางปฏิบัติไม่มีใครทราบว่าเคยมีใครใช้ช่องโหว่ Heartbleed มาเจาะข้อมูลแบบนี้ไปก่อนหรือไม่ (แต่ทุกคนมโนกันว่า NSA เคยทำแน่ๆ ฮา)

เมื่อ private key หลุดออกไปจึงทำให้ข้อมูลที่ถูกเข้ารหัสด้วย key อันนั้น (เช่น รหัสผ่านที่เราใช้เข้าเว็บไซต์ เลขบัตรเครดิต) ไม่ปลอดภัยตามไปด้วยนั่นเองครับ

ตอนนี้คงเป็นหน้าที่ของเว็บไซต์และบริการออนไลน์ต่างๆ ที่จะสอบสวนดูว่าตัวเองได้รับผลกระทบจาก Heartbleed มากน้อยแค่ไหน รายละเอียดลองดูในข่าวเก่าๆ ของ Blognone

ผู้ใช้ควรทำตัวอย่างไรให้ปลอดภัยจาก Heartbleed

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

นอกจากนี้เราอาจใช้มาตรการด้านความปลอดภัยอื่นๆ นอกเหนือจากรหัสผ่านในการปกป้องข้อมูลของเรา (เพราะรหัสผ่านอย่างเดียวอาจไม่ปลอดภัยจาก Heartbleed) เช่น เปิดใช้งาน Two-step Verification บนเว็บไซต์หรือบริการออนไลน์ต่างๆ

สรุปใน 5 บรรทัด

  1. เราส่งข้อมูลสำคัญที่เป็นความลับ เช่น รหัสผ่าน โดยเข้ารหัสผ่านมาตรฐาน SSL/TLS
  2. ซอฟต์แวร์เข้ารหัสตามมาตรฐาน SSL/TLS ที่ได้รับความนิยมสูงที่สุดในโลกคือ OpenSSL
  3. OpenSSL มีบั๊ก (ชื่อ Heartbleed) ที่ทำให้กุญแจการเข้ารหัส "อาจ" รั่วได้
  4. ข้อมูลที่เคยส่งผ่าน SSL/TLS ไปยังเว็บไซต์ต่างๆ จึง "อาจ" รั่วได้
  5. ไม่มีใครรู้ว่าคำว่า "อาจ" มันมีโอกาสโดนจริงๆ มากน้อยแค่ไหน ดังนั้นควรป้องกันตัวไว้ก่อน (โดยการเปลี่ยนรหัสผ่าน)

ข้อมูลเพิ่มเติม

บทความนี้ไม่ได้อธิบายรายละเอียดเชิงเทคนิคของ Heartbleed แบบลงลึก ใครที่สนใจสามารถดูได้จากวิดีโอข้างล่างครับ (ทำโดย Zulfikar Ramzan ผู้เชี่ยวชาญด้านความปลอดภัยจากบริษัท Elastica)

บทความอ่านประกอบ: รายละเอียด Heartbleed จากต้นฉบับ, Vox

Get latest news from Blognone

Comments

By: MizNyze
iPhoneWindows
on 12 April 2014 - 18:39 #694876
MizNyze's picture

มันดูได้มั๊ยครับว่าเว็บนี้ปลอดภัยแล้วหรือยัง เพราะถ้าเราเปลี่ยน password ในขณะที่เว็บก็ยังไม่ได้ Update OpenSSL แล้วมันก็น่าจะยังไม่ปลอดภัยอยู่ดีหรือเปล่าครับ ?

By: Ford AntiTrust
ContributorAndroidBlackberryUbuntu
on 12 April 2014 - 19:02 #694880 Reply to:694876
Ford AntiTrust's picture

ส่วนใหญ่ update patch แล้วมักจะ revoke และ re-key ตัว SSL certificate ด้วยครับ เช็คได้จากที่ browser ว่าเพิ่งขอใหม่มามาดๆ หรือไม่ (ช่วงหลังวันที่ 8/4/2014)

By: chayasorn
ContributorWindows PhoneWindows
on 13 April 2014 - 12:32 #694967 Reply to:694880

อย่างของ Blognone ตัว Certification valid ตั้งแต่วันที่ 2 มกราคม ปีนี้ (ผมเข้าไปดูโดยกดที่รูปแม่กุญแจใน Address Bar) แสดงว่ายังไม่ได้ทำการออก Private key หลังจากมีการเปิดเผยบั๊ก Heartbleed ผมเข้าใจถูกรึเปล่าครับ
ส่วนที่ไม่ได้เปลี่ยน Private key อาจจะเพราะไม่ได้รับผลกระทบ หรือกำลังอยู่ในขั้นตอนการเปลี่ยนอยู่อันนี้เป็นอีกเรื่องหนึ่งใช่มั๊ยครับ

By: lancaster
Contributor
on 13 April 2014 - 12:57 #694975 Reply to:694967

เข้าใจถูกต้องครับ

ถ้าไม่ได้เปลี่ยน private key มี 2 กรณีคือ

  1. ไม่ได้รับผลกระทบแต่แรก
  2. ได้รับผลกระทบแล้วยังไม่แก้

ส่วนกรณีของ blognone ลองเทสแล้วคือไม่ได้รับผลกระทบครับ

By: Ford AntiTrust
ContributorAndroidBlackberryUbuntu
on 13 April 2014 - 13:09 #694976 Reply to:694967
Ford AntiTrust's picture

ถ้ามั่นใจว่าไม่ได้รับผลกระทบก็ไม่ต้อง re-key ใหม่ตาม rstp บอกครับ

By: chayasorn
ContributorWindows PhoneWindows
on 13 April 2014 - 15:03 #694994 Reply to:694967

ขอบคุณคุณ Ford AntiTrust และคุณ Lancaster มากๆ ครับ

By: tanapon000 on 12 April 2014 - 18:57 #694877
tanapon000's picture

งงตรง private key public key คือถ้าเราเข้ารหัสข้อมูลด้วยpublic key แปลว่าใครๆก็รู้keyนี้ แล้วเราเอามาถอดรหัสด้วย public keyอันเดิมเลยไม่ได้หรอครับ

By: Ford AntiTrust
ContributorAndroidBlackberryUbuntu
on 12 April 2014 - 19:20 #694881 Reply to:694877
Ford AntiTrust's picture

public key เข้ารหัส ใช้ private key ถอดออกมาครับ

ฉะนั้นถ้าเข้ารหัสไปแล้วถอดออกมาด้วย public key ไม่ได้ครับ

By: mk
FounderAndroid
on 12 April 2014 - 19:11 #694883 Reply to:694877
mk's picture

มันคือ "กุญแจอสมมาตร" ไงครับ เข้ารหัสด้วย public key ต้องใช้ private key ถอดรหัส

By: thsecmaniac
AndroidWindows
on 12 April 2014 - 19:35 #694887 Reply to:694877

ในการเข้ารหัสลับแบบ Public Key Infrastructure (PKI) เราไม่สามารถใช้ key ชนิดเดียวกันมาทั้งเข้ารหัสลับและถอดรหัสลับในคราวเดียวกันได้ครับ เพราะในกระบวนการเข้ารหัสลับแบบ PKI มันจะมีสมการคณิตศาสตร์ที่การจะได้ผลลัพธ์หนึ่งเดียวต้องใช้ทั้ง Public key กับ private key ที่เข้าคู่กันได้เท่านั้นถึงจะได้ผลลัพธ์นั้นครับ

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

By: lancaster
Contributor
on 12 April 2014 - 19:40 #694888 Reply to:694877
  1. เข้าด้วย pub ต้องถอดด้วย pri เท่านั้น
  2. เข้าด้วย pri ต้องถอดด้วย pub เท่านั้น

สองข้อนี้เป็นกฎทางคณิตศาสตร์ที่ยัง break ไม่ได้ครับ

จริงๆ pub/pri มันก็คือ key คู่กันเนี่ยแหละ จับสลับกันก็ยังทำงานได้ไม่ต่างกัน

By: thsecmaniac
AndroidWindows
on 12 April 2014 - 20:19 #694889 Reply to:694888

เพิ่มเติม

จุดประสงค์ของการเข้ารหัสลับแบบ Public Key Infrastructure ของสองข้อข้างบนต่างกันนะครับ

ข้อ 1 จุดประสงค์คือ ความลับเฉพาะของข้อมูล
ข้อ 2 จุดประสงค์คือ การพิสูจน์ตัวตนของเจ้าของข้อมูล

By: lew
FounderJusci's WriterMEconomicsAndroid
on 21 April 2014 - 12:45 #696946 Reply to:694888
lew's picture

ไม่ถูกนักนะครับ

public key ในระบบ RSA มันเป็นผลคูณของเลข prime มาแล้วรู้ public จะสร้าง private ได้ยากมาก (เป็นไปไม่ได้ในชาตินี้ ถ้าไม่มีรูโหว่อื่น)

แต่หากรู้ private key (ภาษาอ่านไม่รุ้เรื่องมันคือ multiplicative inverse ของ coprime ของ e) ภาษาง่ายๆ คือจะรู้ค่า prime ที่ใช้คูณได้ง่าย ทำให้สร้าง public key กลับขึ้นมาได้

ตัวอย่างการใช้งานในโลกความเป็นจริง เช่น SSH หากเราทำไฟฃ์ public key หาย สร้างสามารถสร้างใหม่ด้วย

ssh-keygen -f ~/.ssh/id_rsa -y > ~/.ssh/id_rsa.pub


lewcpe.com, @wasonliw

By: tanapon000 on 12 April 2014 - 21:57 #694893 Reply to:694877
tanapon000's picture

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

By: LazarusSP1
ContributoriPhone
on 13 April 2014 - 03:13 #694925 Reply to:694893

แนะนำให้ไปหาอ่านในเรื่องของการเข้ารหัส Asymmetric Cryptography ไปพลางๆ ครับ ยาวมาก

By: tanapon000 on 13 April 2014 - 06:19 #694930 Reply to:694925
tanapon000's picture

ทั้งสองฝ่ายต้องสร้างตัวเลขลับสำหรับตัวเองขึ้นมา
ฝ่ายเริ่มต้นส่งพารามิเตอร์ คือ n และ p ให้กับอีกฝ่าย
ทั้งสองฝ่ายแลกค่า A = n^a mod p และ B = n^b mod p ให้อีกฝ่าย
ทั้งสองฝ่ายมีความลับร่วมกันที่คนอื่นไม่สามารถรับรู้ได้

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

ปล.ผมไม่ได้เรียนด้านนี้ แต่ผมอ่านแล้วสงสัย ถ้ามันลึกไปจะอธิบายก็ขออภัย

By: Iamz
AndroidWindows
on 13 April 2014 - 18:49 #695004 Reply to:694930

ตามที่ผมเข้าใจคือฝั่ง A ก็สร้าง a ของตัวเอง ฝั่ง B ก็สร้าง b ของตัวเอง
ทั้งสองฝ่ายใช้ n กับ p เหมือนกันซึ่งไม่เป็นความลับ
ฝั่ง A ส่งค่า n^a mod p ไปให้ฝั่ง B เอาไปใช้คำนวณ (n^a)^b mod p
ฝั่ง B ส่งค่า n^b mod p ไปให้ฝั่ง A เอาไปใช้คำนวณ (n^b)^a mod p
และเนื่องจาก (n^a)^b mod p == (n^b)^a mod p ทั้งสองฝ่ายก็เลยใช้ค่านี้เป็น "ความลับร่วมกัน"​ ที่ไม่มีคนอื่นรู้ได้

By: skuma
iPhoneWindows PhoneAndroidBlackberry
on 12 April 2014 - 20:51 #694891
skuma's picture

เข้าใจง่ายดีครับ ขอบคุณครับ :D

By: JackieNP
ContributorUbuntu
on 12 April 2014 - 22:48 #694896
JackieNP's picture

เข้าใจขึ้นเยอะ ขอบคุณครับ


รักนะคะคนดีของฉัน

By: hisoft
ContributorWindows PhoneWindows
on 12 April 2014 - 23:16 #694900
hisoft's picture

ขอบคุณครับ ฮาตรง setup ในคลิป :p

แล้วนี่ mirror เว็บนี้เหรอครับ -*-

By: inkirby
ContributoriPhoneAndroidIn Love
on 13 April 2014 - 09:42 #694937 Reply to:694900
inkirby's picture

เรียกซะมุ้งมิ้งเลยครับ​ <3


Dream high, work hard.

By: chayasorn
ContributorWindows PhoneWindows
on 13 April 2014 - 12:29 #694963

ขออภัยครับ ถามผิดตำแหน่ง ขออนุญาตลบนะครับ

By: Khow
Windows PhoneAndroid
on 16 April 2014 - 12:19 #695580

ผมเองก็กำลังเรียนเรื่องนี้อยู่เลย ปวดหัวสุดๆอ่านไปสอบด้วย
เดือนนี้ Heart bleed ออกสอบอีกต่างหาก

By: angel13th
Android
on 16 April 2014 - 18:49 #695710
angel13th's picture

...โชคดีที่ใช้ ver เก่าตั้งแต่ปี 2008