การเปลี่ยนเส้นทาง http ไปที่ https หรือไม่

247

ฉันเพิ่งติดตั้งใบรับรอง SSL บนเซิร์ฟเวอร์ของฉัน

จากนั้นตั้งค่าการเปลี่ยนเส้นทางสำหรับการรับส่งข้อมูลทั้งหมดในโดเมนของฉันบนพอร์ต 80 เพื่อเปลี่ยนเส้นทางไปยังพอร์ต 443

กล่าวอีกนัยหนึ่งhttp://example.comปริมาณการใช้งานทั้งหมดของฉันถูกเปลี่ยนเส้นทางไปยังhttps://example.comหน้าเว็บเวอร์ชันที่เหมาะสม

การเปลี่ยนเส้นทางเสร็จสิ้นในไฟล์ Apache Virtual Hosts ของฉันด้วยสิ่งนี้ ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]

คำถามของฉันคือมีข้อ จำกัด ในการใช้ SSL หรือไม่

เนื่องจากนี่ไม่ใช่ 301 Redirect ฉันจะสูญเสียการเชื่อมโยง / การจัดอันดับในเครื่องมือค้นหาโดยการเปลี่ยนเป็นลิงก์httpsหรือไม่

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

ปัญหาที่อัปเดตแล้ว

Bing สร้างภาพหน้าจอนี้จากเว็บไซต์ของฉันอย่างน่าประหลาดใจในตอนนี้เมื่อใช้ HTTPS ทุกที่ ...

ป้อนคำอธิบายรูปภาพที่นี่

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

12

[WTF - ฉันไม่สามารถเพิ่มคำตอบ (แต่ดูเหมือนว่าฉันมีตัวแทนเพียงพอ)] คำตอบของฉัน (บางส่วน) เป็นไปได้ว่าบางครั้งมันก็ไม่ดี พิจารณาส่งรหัส COOKIE หรือ API ใน GET ผ่าน HTTP หากไซต์ของคุณเปลี่ยนเส้นทางคำขอ HTTP ไปยังคำขอ HTTPS การโทรเหล่านี้จะใช้งานได้ แต่รหัส COOKIE หรือ API จะถูกส่งให้ชัดเจน API บางตัวปิด HTTP ซึ่งเป็นวิธีที่แข็งแกร่งกว่า - ไม่มี HTTP เลยดังนั้นคุณจึงไม่สามารถใช้งานได้เว้นแต่คุณจะใช้ HTTPS ตัวอย่าง: "คำขอ API ทั้งหมดจะต้องทำผ่าน HTTPS การโทรผ่าน HTTP ธรรมดาจะล้มเหลว" จากStripe.com/docs/api?lang=php#authentication

— codingoutloud

8

@coutoutloud - ทางเลือกคือสิ่งทั้งหมดเกิดขึ้นผ่าน HTTP โดยไม่มี HTTPS เลย มันจะดีกว่านี้ได้อย่างไร?

— Mark Henderson

3

@BenCrowell นั่นเป็นเพราะพอร์ทัลที่ถูกกักขังนั้นดูน่ากลัวอย่างมากเช่นการsslstripโจมตีเปลี่ยนเส้นทางแบบ (พวกเขาทั้งคู่ร้องขอการแย่งชิงกลางคน) ดังนั้นเบราว์เซอร์HSTS -aware จะบล็อกพวกเขาทั้งสอง

— Jeffrey Hantin

3

ทราบว่าใช้ https หมายความว่าทุกสิ่งที่คุณรวมถึงควรที่จะ https หรือมันอาจจะไม่โหลด - เช่นโหลด jQuery ใช้src="://example.com/jquery.js"- ทราบขาดhttpหรือhttpsเพื่อให้เบราว์เซอร์โหลดที่เหมาะสมหนึ่ง ฉันมีฝันร้ายที่พยายามทำให้ Amazon โหลดบางอย่างเพื่อโหลดอย่างถูกต้องเนื่องจาก API (โหลดผ่าน https) สร้างลิงก์ http - หมายความว่ามันไม่ทำงานอย่างถูกต้องจนกว่าฉันจะพบพารามิเตอร์ที่ไม่มีเอกสารในการสลับลิงก์ https

— พื้นฐาน

3

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

— Mark Henderson

316

การ[R]ตั้งค่าสถานะด้วยตนเองคือการ302เปลี่ยนเส้นทาง ( Moved Temporarily) หากคุณต้องการคนที่ใช้เว็บไซต์ HTTPS ของคุณจริงๆ (คำใบ้: คุณทำ) คุณควรใช้[R=301]การเปลี่ยนเส้นทางแบบถาวร:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L]

301ช่วย google-Fu ทั้งหมดของคุณและ pageranks ได้ยากเหมือนเดิม ตรวจสอบให้แน่ใจว่าmod_rewriteเปิดใช้งานแล้ว:

a2enmod rewrite

ในการตอบคำถามที่แน่นอนของคุณ:

การเปลี่ยนเส้นทาง http ไปที่ https หรือไม่

ไม่มีทาง. มันดีมาก

— มาร์คเฮนเดอร์สัน
แหล่งที่มา

3

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

— JasonDavis

9

@jasondavis เฉพาะในกรณีที่คุณไม่ได้ใช้เวลาไม่กี่นาทีในการเพิ่มประสิทธิภาพของมัน

— Michael Hampton

10

"ใช้ทรัพยากรเซิร์ฟเวอร์จำนวนมากเพื่อเรียกใช้บนทุกหน้า" CPU สมัยใหม่มีคุณสมบัติการเร่งความเร็วการเข้ารหัสที่ทำให้ SSL เกือบฟรี ไม่ต้องกังวลเรื่องค่าใช้จ่าย

— Adam Davis

41

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

— 200_success

6

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

— Jon Hanna

49

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

ตรวจสอบลิงก์ทั้งหมดภายในไซต์และตรวจสอบให้แน่ใจว่าพวกเขาใช้ HTTPS หากคุณระบุชื่อโดเมนของคุณเองในลิงก์ดังนั้นคุณจะไม่ทำให้เกิดการเปลี่ยนเส้นทางของคุณเอง
อัปเดต<meta property="og:url"เป็นใช้เวอร์ชัน https ของโดเมนของคุณ
หากคุณใช้<base href=อัปเดตอีกครั้งเพื่อใช้ HTTPS
ติดตั้งโปรโตคอล SPDYถ้าเป็นไปได้
ตรวจสอบให้แน่ใจว่าได้ใช้ CSS Image sprites เท่าที่จะทำได้เพื่อลดจำนวนคำขอ
อัปเดตแผนผังไซต์ของคุณเพื่อระบุสถานะ https ดังนั้นสไปเดอร์เมื่อเวลาผ่านไปจะเรียนรู้การเปลี่ยนแปลงนี้
เปลี่ยนค่ากำหนดของ Search Engine เช่น Google Webmaster Tools เพื่อให้ใช้ HTTPS
หากเป็นไปได้ให้โหลดสื่อบันทึกการหยุดไปยังเซิร์ฟเวอร์ HTTPS CDN

หากได้กล่าวถึงข้างต้นแล้วฉันสงสัยว่าคุณจะมีปัญหามากมาย

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

SPDY เป็นคำแนะนำที่ดี มีแม้ดูเหมือนจะเป็นโมดูลการเพิ่มการสนับสนุน SPDY เพื่อ Apache 2.x

— Calrion

18

การใช้ "//yourserver.com/some-uri" แทน " yourserver.com/some-uri " ช่วยแก้ปัญหา (1) เนื่องจากเบราว์เซอร์จะเลือกสคีมาที่เหมาะสม (http หรือ https) ขึ้นอยู่กับสคีมาที่โหลดหน้าเว็บด้วย .

— MauganRa

1

@MauganRa ยกเว้นแน่นอนมันเป็นลิงก์จากหน้าบทความ http ไปยังหน้าเข้าสู่ระบบ https เช่น

— Mołot

4

Google เห็น URL ที่มีผู้เยี่ยมชมผ่านทางRefererส่วนหัว ตัวอย่างเช่นไซต์นี้ใช้ jQuery จาก CDN ของ Google และเบราว์เซอร์ของฉันจะส่งคำขอไปยัง Google ทุกครั้งที่ฉันโหลดไซต์ซ้ำ ดังนั้นRefererส่วนหัวจะถูกส่งไปยัง Google ซึ่งถูกกำหนดเป็น URL ของเว็บไซต์นี้ ดังนั้น Google สามารถติดตามเว็บไซต์ที่ฉันเยี่ยมชมในช่วงเวลาที่ที่อยู่ IP ของฉันไม่เปลี่ยนแปลง (และถ้าฉันใช้บริการของ Google ในช่วงเวลานี้ Google สามารถเชื่อมต่อข้อมูลนี้กับบัญชี Google ของฉัน)

— Stephan Kulla

1

สำหรับ 1) ฉันเพิ่งค้นหาและแทนที่ในฐานข้อมูล MySQL เป็น http ... ฉันใช้ WordPress ดังนั้นมันจึงเป็นเรื่องง่ายที่จะอัปเดตลิงค์นับร้อย

— JasonDavis

38

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

การเปลี่ยนเส้นทางจาก http ไปยัง https คำตอบนั้นไม่ง่ายเลย

การเปลี่ยนเส้นทางจะทำให้ผู้ใช้ของคุณง่ายขึ้นมากเพียงพิมพ์ whateversite.com และเปลี่ยนเส้นทางไปที่ https

แต่. ถ้าบางครั้งผู้ใช้อยู่ในเครือข่ายที่ไม่ปลอดภัย (หรืออยู่ใกล้กับTroy Hunt และ Pineapple ของเขา ) จากนั้นผู้ใช้จะขอhttp://whateversite.comจากนิสัยเก่า นั่นคือ http ที่สามารถประนีประนอมได้ เปลี่ยนเส้นทางสามารถชี้ไปhttps://whateversite.com.some.infrastructure.long.strange.url.hacker.org สำหรับผู้ใช้ทั่วไปมันจะดูค่อนข้างถูกกฎหมาย แต่การรับส่งข้อมูลสามารถถูกดัก

ดังนั้นเราจึงมีข้อกำหนดการแข่งขันสองประการที่นี่: เป็นมิตรกับผู้ใช้และปลอดภัย โชคดีที่มีวิธีการรักษาที่เรียกว่าหัว HSTS ด้วยคุณสามารถเปิดใช้งานการเปลี่ยนเส้นทาง เบราว์เซอร์จะย้ายไปยังไซต์ที่ปลอดภัย แต่ต้องขอบคุณส่วนหัว HSTS ที่จำได้เช่นกัน เมื่อผู้ใช้พิมพ์ whateversite.com นั่งบนเครือข่ายที่ไม่ปลอดภัยเบราว์เซอร์จะไปที่ https ทันทีโดยไม่ต้องข้ามผ่านการเปลี่ยนเส้นทางผ่าน http ถ้าคุณไม่จัดการกับข้อมูลที่ละเอียดอ่อนมากฉันคิดว่านั่นเป็นการแลกเปลี่ยนที่ยุติธรรมระหว่างความปลอดภัยและการใช้งานสำหรับไซต์ส่วนใหญ่ (เมื่อฉันเพิ่งตั้งค่าแอปพลิเคชันที่จัดการเวชระเบียนฉันไปที่ https ทั้งหมดโดยไม่เปลี่ยนเส้นทาง) น่าเสียดายที่ Internet Explorer ไม่รองรับ HSTS ( แหล่งที่มา) ดังนั้นหากกลุ่มเป้าหมายของคุณส่วนใหญ่ใช้ IE และข้อมูลมีความละเอียดอ่อนคุณอาจต้องการปิดใช้งานการเปลี่ยนเส้นทาง

ดังนั้นหากคุณไม่ได้กำหนดเป้าหมายผู้ใช้ IE ให้ไปข้างหน้าและใช้การเปลี่ยนเส้นทาง แต่เปิดใช้งานส่วนหัว HSTS ด้วย

— Anders Abel
แหล่งที่มา

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

— Velox

3

@Velox - ฉันไม่คิดว่าความหมายของ "ผู้คนถือว่าพวกเขาปลอดภัยเพราะจุดสิ้นสุดคือ HTTPS โดยไม่สนใจข้อเท็จจริงที่ว่าข้อมูลทั้งหมดที่ส่งไปยังหน้าเว็บใน GETs หรือ POSTs เป็นข้อความธรรมดา" ค่อนข้างแม่นยำ ในขณะที่มี gotchas อยู่บ้าง GET Params การค้นหาจะไม่เดินทางในระหว่างการขนส่งผ่าน HTTPS ดูตัวอย่าง: stackoverflow.com/questions/323200/…ส่วนของข้อมูล POST ได้รับการคุ้มครองในขณะที่ยังไม่เสี่ยงต่อการบันทึกและส่วนหัวของผู้อ้างอิง

— codingoutloud

@ การเข้ารหัสออกมานั่นคือจุดของฉัน พวกเขาจะถูกเข้ารหัส HTTPS แต่ในคำขอเริ่มต้นไปยังหน้า HTTP พวกเขาไม่ได้

— Velox

1

@Velox - หากทั้งเว็บไซต์กำลังเปลี่ยนเส้นทางไปยัง HTTPS ดังนั้นจึงไม่น่าที่พารามิเตอร์ GET ใด ๆ จะถูกส่งก่อนที่ HTTPS จะเริ่มเตะ (และทุกอย่างจะยังคงเป็น HTTPS หลังจากจุดนั้น) ยังคงมีคำขอเริ่มต้นหนึ่งที่จะส่งคุกกี้ซึ่งสามารถแก้ไขได้ด้วย HSTS ... และหน้าต่างการโจมตีขนาดเล็กสำหรับ SSLStrip ซึ่งอาจถูกจาวาสคริปต์เอาชนะได้ แต่นั่นคือการแข่งขันทางอาวุธของตนเอง

— Brilliand

@Billiand จุดยุติธรรม แต่จุดอ่อนในการรักษาความปลอดภัยทำให้ทุกอย่างอ่อนแอ พิจารณาที่คุ้มค่าเสมอ

— Velox

22

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

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

301รหัสสถานะบ่งชี้ถาวรเปลี่ยนเส้นทางสอนลูกค้าสามารถที่จะใช้ URL ที่เชื่อถือได้สำหรับการเชื่อมต่อในอนาคต (เช่นอัปเดตบุ๊ก)

หากคุณให้บริการเว็บไซต์ผ่าน TLS / SSL เท่านั้นฉันขอแนะนำแนวทางเพิ่มเติมเพื่อเปิดใช้งาน HTTP Strict Transport Security (HSTS) ในโฮสต์เสมือนที่ปลอดภัยของคุณ:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

ส่วนหัวนี้สั่งให้ลูกค้าที่มีความสามารถ (ส่วนใหญ่ในวันนี้ฉันเชื่อว่า) พวกเขาควรใช้ HTTPSกับโดเมนที่ระบุ ( secure.example.comในกรณีนี้) ในไม่1234กี่วินาทีถัดไป ; includeSubdomainsส่วนเป็นตัวเลือกและแสดงให้เห็นว่าคำสั่งใช้ไม่เพียงเพื่อโดเมนปัจจุบัน แต่ใด ๆ ภายใต้มัน (เช่นalpha.secure.example.com) โปรดทราบว่าเบราว์เซอร์ส่วนหัว HSTS ได้รับการยอมรับเฉพาะเมื่อให้บริการผ่านการเชื่อมต่อ SSL / TLS!

เพื่อทดสอบการกำหนดค่าเซิร์ฟเวอร์ของคุณกับแนวปฏิบัติที่ดีที่สุดในปัจจุบันทรัพยากรฟรีที่ดีคือบริการทดสอบเซิร์ฟเวอร์ SSL ของ Qualys ฉันจะตั้งเป้าหมายที่จะทำคะแนนอย่างน้อย A- (คุณไม่สามารถรับมากกว่านั้นด้วย Apache 2.2 เนื่องจากการขาดการสนับสนุนสำหรับการเข้ารหัสแบบวงรีรูปไข่)

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

ฉันควรเพิ่มการส่งส่วนหัวStrict-Transport-Security: max-age=0จะคัดค้านคำสั่งก่อนหน้าใด ๆ เช่นเคยจะต้องส่งผ่าน HTTPS เพื่อให้ได้รับการยอมรับ แต่เป็นวิธีที่สะดวกในการยกเลิกสิ่งต่าง ๆ หากคุณตัดสินใจว่าคุณต้องใช้ HTTP ในโดเมนด้วย

— Calrion

5

ว้าว ! เปลี่ยนเส้นทาง HTTP ไปยัง HTTPS เป็นสิ่งที่ดีมากและฉันไม่เห็นข้อเสียเปรียบใด ๆ

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

นอกจากนี้วิธีการตั้งค่า Apache เพื่อเปลี่ยนเส้นทางไปยัง HTTPS นั้นก็ถือว่าใช้ได้

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

5

การเปลี่ยนเส้นทาง http ไปที่ https หรือไม่

ไม่เลย. จริงๆแล้วมันเป็นสิ่งที่ดีที่จะทำ!

เมื่อเปลี่ยนเส้นทาง:

มันอาจมีประสิทธิภาพมากขึ้นโดยการกำจัดการเขียนใหม่ทั้งหมด นี่คือการกำหนดค่าของฉันในสถานการณ์ที่คล้ายกัน ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

— Pothi Kalimuthu
แหล่งที่มา

4

HTTPS ไม่ผิดพลาดอย่างแน่นอน แน่นอนว่าการบังคับ HTTPS เป็นสิ่งที่ดี ช่วยป้องกันอาชญากรปกติไม่ให้ทำสิ่งที่ไม่ดีกับผู้ใช้

แต่โปรดอย่าลืมตรวจสอบการตั้งค่า SSL ของคุณเช่นการตั้งค่า SSLCiphers ปิดใช้งานสิ่งต่าง ๆ เช่น RC4 crypto, โปรโตคอล SSLv2 และ SSLv3 นอกจากนี้คุณควรตรวจสอบว่าไม่ว่าจะเป็นระบบ librypts ของระบบของคุณรองรับ TLS1.2 หรือไม่ (ซึ่งเป็นสิ่งที่คุณต้องการมี)

เปิด SSL เป็นสิ่งที่ดี

— Tobias Mädel
แหล่งที่มา

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

— Gilles

ขออภัยสิ่งที่ ? มีการดำเนินการจำนวนมากบน Linux ที่ยืนยันในเอนโทรปีที่ได้มาจากฮาร์ดแวร์มากกว่าเอนโทรปีที่ใช้พื้นฐานของ PRNG ซึ่งอาจดีพอสำหรับการใช้งานเอนโทรปี เป็นไปได้อย่างแน่นอนที่สุดที่จะเริ่มต้นด้วยเอนโทรปีที่เพียงพอบนระบบลีนุกซ์ แต่โดยมากเกินไปที่จะระบายพูลทำให้การดำเนินการบางอย่างต้องปิดกั้น

— MadHatter

3

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

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

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

— Håkan Lindqvist

3

นี่คือปัญหา brushstroke ในวงกว้าง:

MITM / SSLSTRIP : นี่เป็นข้อแม้ที่ยิ่งใหญ่ หากคุณกำลังจะให้บริการเว็บไซต์ของคุณผ่าน HTTPS แล้วปิดการใช้ HTTP บนเว็บไซต์ มิเช่นนั้นคุณจะปล่อยให้ผู้ใช้เปิดการโจมตีแบบ Man-in-the-middle เช่น SSLSTRIP ซึ่งจะสกัดกั้นการร้องขอและให้บริการอย่างเงียบ ๆ ผ่าน HTTP โดยแทรกสคริปต์มัลแวร์ของตัวเองลงในสตรีม หากผู้ใช้ไม่ได้สังเกตเห็นพวกเขาจะคิดว่าเซสชั่นของพวกเขาปลอดภัยเมื่อมันไม่จริง
- อย่างไรก็ตามปัญหานี้คือถ้าเว็บไซต์ของคุณเป็นเว็บไซต์สาธารณะและคุณเพียงปิดการใช้งาน HTTP อย่างไม่สม่ำเสมอคุณอาจสูญเสียผู้เข้าชมจำนวนมาก มันอาจจะไม่เกิดขึ้นกับพวกเขาที่จะลอง HTTPS ถ้าเว็บไซต์จะไม่โหลดด้วย HTTP
หากไซต์ของคุณต้องการการเข้าสู่ระบบที่ปลอดภัยดังนั้นเซสชันผู้ใช้ทั้งหมดควรจะปลอดภัย อย่าตรวจสอบสิทธิ์ผ่าน HTTPS จากนั้นเปลี่ยนเส้นทางผู้ใช้กลับไปที่ HTTP ถ้าคุณทำเช่นนั้นคุณจะปล่อยให้ผู้ใช้เสี่ยงต่อการถูกโจมตีจาก MITM วิธีมาตรฐานในการรับรองความถูกต้องในปัจจุบันคือการตรวจสอบสิทธิ์หนึ่งครั้งจากนั้นจึงส่งโทเค็นการรับรองความถูกต้องไปมา (ในคุกกี้) แต่ถ้าคุณรับรองความถูกต้องผ่าน HTTPS แล้วเปลี่ยนเส้นทางไปที่ HTTP ดังนั้น man-in-the-middle สามารถดักคุกกี้นั้นและใช้ไซต์ราวกับว่าพวกเขาเป็นผู้ใช้ที่ผ่านการรับรองความถูกต้องของคุณ
ปัญหา "ประสิทธิภาพ" กับ HTTPS นั้นใช้เพื่อจุดประสงค์ในทางปฏิบัติทั้งหมดที่ จำกัด ไว้ในการจับมือที่เกี่ยวข้องในการสร้างการเชื่อมต่อใหม่ ทำสิ่งที่คุณสามารถทำได้เพื่อลดความต้องการการเชื่อมต่อ HTTPS หลายรายการจาก URL ให้น้อยที่สุด และนั่นเป็นความจริงอย่างแท้จริงแม้ว่าคุณจะให้บริการเนื้อหาของคุณผ่าน HTTP หากคุณอ่าน SPDY คุณจะพบว่าทุกสิ่งที่เกี่ยวข้องกับการพยายามให้บริการเนื้อหาทั้งหมดจาก URL เดียวผ่านการเชื่อมต่อเดียว ใช่การใช้ HTTPS มีผลต่อการแคช แต่วันนี้มีกี่เว็บไซต์ที่มีเนื้อหาแบบคงที่และแคชได้หรือไม่ คุณมีแนวโน้มที่จะได้รับผลตอบแทนที่มากขึ้นจากการใช้แคชในเว็บเซิร์ฟเวอร์ของคุณเพื่อลดการสืบค้นฐานข้อมูลซ้ำซ้อนเพื่อดึงข้อมูลที่ไม่เปลี่ยนแปลงซ้ำแล้วซ้ำอีกและป้องกันเส้นทางโค้ดราคาแพงจากการดำเนินการบ่อยกว่าที่จำเป็น

— เครก
แหล่งที่มา

สิ่งที่คุณสามารถทำได้เพื่อจัดการกับsslstripที่แท้จริงคือการใช้ HSTS (ควรที่จะโหลดการตั้งค่า HSTS ของคุณล่วงหน้า ) ไม่ว่าคุณจะรับคำขอผ่าน HTTP ธรรมดาหรือไม่สำคัญในเรื่องนี้ MITM สามารถตอบผ่าน HTTP ธรรมดา (อาจเป็นไปได้ที่จะส่งไปยังไซต์ HTTPS ของคุณ) แม้ว่าคุณจะยอมรับเฉพาะคำขอ HTTPS ก็ตาม

— Håkan Lindqvist

@ HåkanLindqvistฉันได้รับ downvote จากคุณจริงๆเหรอ? ฉันได้ให้คำแนะนำที่ไม่ดีหรือคำแนะนำที่ดีเกี่ยวกับการไม่รับรองความถูกต้องผ่าน HTTPS แล้วเปลี่ยนเป็น HTTP สำหรับช่วงที่เหลือของเซสชันหรือไม่ ฉันให้คำแนะนำที่ไม่ดีเกี่ยวกับเรื่องประสิทธิภาพของ HTTPS หรือไม่ นอกจากนี้หากลูกค้าพยายามเชื่อมต่อโดยใช้ HTTPS ในขั้นต้น MITM จะไม่สามารถดักจับและตอบสนองได้โดยไม่ทริกเกอร์การแจ้งเตือนในเบราว์เซอร์เพราะใบรับรองของพวกเขาจะไม่ตรงกันเว้นแต่ว่าใบรับรองของพวกเขาถูกขโมยหรือปลอมแปลงสำเร็จ ในทางกลับกันหากไซต์ยอมรับการเชื่อมต่อ HTTP การสกัดกั้นจะง่ายกว่า ไม่ว่าจะด้วยวิธีใด HTTPS จะยกระดับแถบ

— เครก

.. และแน่นอนฉันเห็นด้วยอย่างยิ่งกับการใช้ HSTS

— เครก

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

— Håkan Lindqvist

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

— เครก

1

นี่ไม่ใช่คำตอบทางเทคนิคสำหรับคำถามเดิมของคุณ แต่ถ้าคุณใช้ HTTPS ทุกที่ส่วนขยายของ Google Chrome (ฉันแน่ใจว่ามีส่วนขยายที่คล้ายกันในเบราว์เซอร์อื่น) ส่วนขยายจะเปลี่ยนเส้นทางไซต์ที่มี HTTP ไปยังไซต์เดียวกันด้วย HTTPS โดยอัตโนมัติ ฉันใช้มันมาซักพักแล้วและฉันก็ไม่ได้มีปัญหาใด ๆ (ยกเว้นอาจจะช้าลง แต่ฉันยังไม่ได้ทดสอบ) HTTPSEverywhere สามารถเปลี่ยนแปลงได้โดยกฎบางอย่างในฝั่งเซิร์ฟเวอร์ แต่เนื่องจากฉันไม่ได้ทำอะไรมากมายในพื้นที่นั้นฉันไม่แน่ใจเกี่ยวกับรายละเอียดที่แน่นอน

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

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

1

เทคนิคเดียวที่ดึงกลับมาที่ HTTPS ผ่าน HTTP คือการประมวลผลคำขอ HTTPS มีราคาแพงกว่า HTTP ธรรมดา

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

ด้วยการถือกำเนิดของโปรโตคอลเช่น SPDY ซึ่งต้องการ SSL / TLS ในการทำงานสิ่งนี้จริง ๆ แล้วเป็นการต่อต้านค่าใช้จ่ายในการคำนวณดังกล่าวข้างต้นโดยให้การปรับปรุงประสิทธิภาพที่สำคัญเกี่ยวกับการร้องขอหลายครั้ง

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

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

— Craig

1

มันเป็นการดีที่จะเปลี่ยนเส้นทางไปยัง https แต่ฉันอ่านมันยังขึ้นอยู่กับวิธีที่คุณจัดระเบียบการเปลี่ยนเส้นทาง

การสร้างเซิร์ฟเวอร์เสมือนเฉพาะสำหรับการเปลี่ยนเส้นทางคำขอ HTTP ขาเข้าไปยังการเชื่อมต่อ https ของคุณตามคำแนะนำในคำตอบใน security.stackexchange.comฟังดูดีมากและจะปิดการคุกคามด้านความปลอดภัยเพิ่มเติม การกำหนดค่าใน Apache จะมีลักษณะดังนี้:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>

— ร่วงโรย
แหล่งที่มา