กูเกิลเปิดบริการ HTTPS ใน Gmail มาได้สักระยะแล้ว โดยผู้ใช้สามารถเลือกได้ระหว่าง HTTP และ HTTPS เนื่องจากการใช้ HTTPS มีข้อด้อยคือช้ากว่า HTTP (เราสามารถเลือกใช้ HTTPS แบบถาวรโดยต้องตั้งค่าใน Settings)
แต่ไม่รู้ว่าเกี่ยวกับ Gmail ในจีนโดนโจมตี หรือเปล่า วันนี้กูเกิลออกมาประกาศว่า ต่อจากนี้ไป Gmail จะเปลี่ยนมาใช้ HTTPS เป็นค่า default แล้ว โดยกูเกิลยอมแลกความเร็วกับความปลอดภัยที่เพิ่มมากขึ้น
ผู้ใช้ยังสามารถปิด HTTPS ได้ผ่านตัวเลือก "Don't always use https" และถ้าใครใช้ Gears แล้วเกิดปัญหากับ HTTPS อ่านวิธีแก้ไขได้ครับ
ที่มา - Official Gmail Blog
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- NVIDIA จะไปหยุดที่ตรงไหน ทำไมครองโลกดาต้าเซ็นเตอร์ | Cloudnone EP.22
- ถึงคลาวด์เคราะห์: ทำอย่างไรเมื่อบริการคลาวด์ที่ใช้ถูกยกเลิก | Cloudnone EP. 21
- รู้จักอาชีพ Site Reliability Engineer สำคัญยังไง? | Cloudnone EP. 20
- อธิบาย CrowdStrike ทางเทคนิค ทำไมถึงทำพีซีจอฟ้าเป็นล้านๆ เครื่อง | Cloudnone EP.19
- Kubernetes [Part 2] ยี่ห้อไหนดี งานไหนต้องใช้ แล้วเลือกยังไง? | Cloudnone EP.18
Comments
https นี่เป็นเหตุผลหนึ่งที่ทำให้ webmail อื่นๆ ช้า คราวนี้ก็มาดูกันว่า gmail webmail จะช้าลงขนาดไหน
ผมว่าก็ไม่ได้ช้าน่าเกลียดอะไรนะครับในยุค Adsl สมัยนี้
ผมใช้ Https เป็น Default บน Gmail มานานหลายเดือนแล้วยังไม่รู้สึกเลยว่ามันช้า ก็วิ่งปกติดี เปิด Theme ด้วย
(หรือตรูไม่รู้สึกเองหว่า..)
เปิดดู E-mail รูปภงรูปภาพได้ความเร็วปกติ (พวก FW-Mail นี่มาทีภาพตรึม..)
แถมมีหลายๆทีที่ใช้งานผ่านมือถือด้วย (แบบ Full Text ปกติ ไม่ Mobile เพราะจะดูรูป)
ก็โอเคดีครับ...
ผมลองใช้ http ธรรมดา เปิด ประมาณ 2-3 วิโหลด inbox เสร็จ เปลี่ยนเป็น https เปิดใช้เวลา 8-10 วิเลยทีเดียว
ขึ้นอยู่กับความเร็วของเน็ตแต่ละคนหล่ะครับงานนี้ เพราะ https นี่มัน cache บน proxy ไม่ได้ด้วยซิ แต่ที่แน่ๆ มันช้าลงอย่างรู้สึกได้แน่นอน ...
นั่นข้อดีเลยแหละ..
proxy นี่เป็นเหตุผลหลักเลยที่ผมใช้ https
ดีเลยเพราะหลังๆเริ่มขี้เกียจบอกเพื่อนให้ไปตั้ง https
จำเป็นต้องใช้เลยนะครับ ไม่จำเป็นอย่าปิดนะครับ เพราะเราไม่รู้ครับว่า isp ทำไรกับเราบ้าง
โดยเฉพาะ w3.mict -*-
รู้สึกชื่อนี้จะเจ้าปัญหา ชักเห็นบ่อย w3....
w3g?
บอกตามตรง ถ้าไม่มีข่าวออกมา ก็คงไม่รู้หรอกครับว่าเปลี่ยนเป็น HTTPS แล้ว ความเร็วไม่ตกลงจนน่ากลัว แทบไม่แตกต่าง แต่ถ้าเป็่นช่วงที่ HTTP เป็น Default แล้วปรับ Options ให้เป็น HTTPS ความเร็วจะตกลงจนรู้สึกได้
ใช้มาเกินครึงปีแล้ว ใช้เพราะชอบมันขึ้น Site ID แทน Favicon ตรง AwesomeBar
สวยดี ไม่เกี่ยวกับความปลอดภัยสักนิด (ฮา)
+1
เมล์มีพาสเวิร์ดเพียบ
ปกติใช้
| basic HTML
เลยเร็วอยู่แล๊วววว ^^
@ Virusfowl
I'm not a dev. not yet a user.
บล็อกนอนเป็น https รึเปล่าครับ?
จะทำไปทำไมล่ะครับ?
อยากทำนะครับ อย่างน้อยก็จะได้ช่วยเวลา login
แต่ทุกวันนี้ได้ความอนุเคราะห์เซิร์ฟเวอร์จากทาง cyberbeing.biz อยู่แล้ว ถ้าเปิด https นี่มันจะไปโหลดเซิร์ฟเวอร์มาเกินสมควรไปสักหน่อย
lewcpe.com, @wasonliw
ถ้าจะใช้แค่ส่วน login ใช้ ajax เรียก random key จาก server เพื่อเอามาเข้า hash ก่อนส่งก็น่าจะปลอดภัยขึ้นแล้ว แถมยังไม่เปลืองโหลดมากมายด้วยครับ
มันไร้ประโยชน์ครับ เพราะสุดท้ายแล้วโค้ดที่ใช้ hash มันถูกปลอมจาก man-in-the-middle ได้
lewcpe.com, @wasonliw
ง่า.. เพิ่งเห็น ตอบช้าเลย
man-in-the-middle น่าจะไม่ได้อะไรไปนะ เพราะคีย์ถูก generate จาก server ส่วน password คีย์จากฝั่ง client ก่อนส่งข้อมูลก็ทำการเข้ารหัสเรียบร้อยแล้ว ที่จะโดนขโมยได้ก็จะมีแค่ key กับ password ที่เข้ารหัสแล้ว อาจจะได้เพิ่มเติมคือ algorithm สำหรับการเข้ารหัสที่อยู่ใน javascript ซึ่งถ้าทำไว้ดีคนจะเจาะด้วยวิธีนี้ได้ต้องเตรียม rainbow dictionary สำหรับ algorithm เฉพาะตัวเท่านั้นครับ
ส่วนกรณีถูกปลอม hash ไม่แน่ใจว่าทำด้วยวิธีไหน แต่เท่าที่นึกออก สุดท้ายเมื่อตอนที่เทียบค่าบนฝั่ง server ถ้าไม่ถูกต้องยังไงก็ไม่ถูกต้อง ส่วนข้อมูลที่ได้ไปก็ไม่มีความหมาย เพราะรหัสที่เข้า hash จะเปลี่ยนไปทุกครั้งอยู่แล้ว
ใช้ MITD เปลี่ยน js ที่ควรจะ hash ไม่ให้ hash แล้วค่อยไป hash ที่ผู้โจมตีเพื่อ login ก็ได้ครับ
lewcpe.com, @wasonliw
หมายถึง mitm นะครับ ผมเองก็พลาดไปว่ามันเปลี่ยน content ได้
แต่กรณีที่โดน mitm แล้วเปลี่ยน content น่าจะเป็นคนที่ตั้งใจจะเจาะหน้าเว็บใดเว็บหนึ่งโดยเฉพาะอยู่แล้ว เพราะต้องเตรียมว่าต้องเปลี่ยน content หรือทำหน้าปลอมรอไว้ก่อน ไม่ได้แค่ทำตัวดักดูข้อมูลที่รับส่งกันเท่านั้น
วิธีที่ผมแนะนำไป เมื่อก่อน yahoo หรือเว็บหลายที่ก็ใช้วิธีนี้เพื่อส่งข้อมูล login จากหน้าที่ไม่ได้เป็น https เช่นกัน แต่เนื่องจากไม่ใช่เว็บเล็กจึงเป็นเป้าให้โจมตีโดยธรรมชาติ ปัจจุบันก็หันไปใช้ ssl นานแล้ว แต่ที่แนะนำไปเพราะคิดว่าน่าจะไม่คุ้ม อยากให้ปลอดภัยจริงก็แพงอีก แถม user เองก็ ok, yes, next ตลอด ไม่ได้เช็ค cert กันหรอก แต่ก็เห็นด้วยว่าถ้ามีไว้มันก็ดีกว่า
เพิ่มเติมอีกนิดหน่อย
จากวิธีข้างบนถ้าจะแก้ปัญหาโดนโจมตีด้วย rainbow dictionary ก็ให้ฝั่ง server ส่ง algorithm ที่ random ออกมาด้วยก็ได้ครับ แต่ละครั้งก็จะเข้า hash ไม่เหมือนกันแล้ว
แล้วพูดถึงจริงๆ ถ้า man-in-the-middle เครื่องที่ต้องการโจมตีได้ ผมคงเลือกที่จะ session hijack มากกว่า วุ่นวายน้อยกว่าเยอะ
ต่อไปจะมีข่าว SSL or TLS โดนโจมตีมากขึ้น โดยทางการจีนเป็นผู้สนับสนุนหลักอย่างเป็นทางการ