Wybór domeny do zabezpieczenia

11

Mamy witrynę, która jest obsługiwana zarówno www.example.comi po prostu example.com- nigdy nie robiliśmy żadnego rodzaju zmuszania użytkowników z jednej domeny do drugiej, więc jeśli wylądują example.com, to tam właśnie się zatrzymają, i przypuszczam, że z nich którzy dodadzą do zakładek nasze strony, podzieliliby się około 50/50 (wcześniej pojawił się problem polegający na tym, że niektóre nasze materiały pomijały WWW, a lata później wciąż zauważamy podział ruchu).

Dodajemy teraz SSL. Nie wymuszamy SSL, dopóki użytkownik nie wejdzie na stronę logowania lub rejestracji. W której domenie powinniśmy korzystać z naszego protokołu SSL?

  • www.example.com
  • example.com
  • secure.example.com
  • Coś innego?

Wcześniej robiłem wiele stron SSL, ale zawsze były one zaprojektowane z myślą o SSL i zawsze wymuszaliśmy poddomenę www.

Czy są zalety i wady robienia tego w jakikolwiek sposób? Moje główne obawy dotyczą rozpoznawania plików cookie, ale ponieważ wymuszamy SSL podczas logowania, sesyjny plik cookie i tak zostanie zapisany w domenie SSL. Moją główną troską są ludzie, do których można się udać, https://example.comgdy uruchomimy witrynę https://www.example.comitp.

Innym pytaniem byłoby: „Czy powinienem przepisać tych, którzy wylądowali na stronie innej niż www, na stronę WWW?

domains subdomain https security-certificate Mark Henderson
źródło
W zależności od tego, od kogo kupujesz swój certyfikat, mogą oni bezpłatnie udostępnić ci nagą domenę jako alternatywną nazwę podmiotu. Więc jeśli kupisz www.example.com, możesz uzyskać certyfikat, który obejmuje zarówno www.example.comi example.com.
Michael Hampton

Odpowiedzi:

6

Zwykle wybieram, secure.domain.componieważ daje mi to większą elastyczność w zakresie administracji. Na przykład mogę umieścić tę subdomenę na innym serwerze, za lepszym sprzętem IDS / IPS i ewentualnie podłączyć ją do sieci prywatnej, której nie chcę, aby serwery WWW się stykały.

Jest to dobre miejsce do parkowania rzeczy wielofunkcyjnych, takich jak:

  • secure.domain.com/checkout/
  • secure.domain.com/portal/
  • secure.domain.com/support/

... itd.

Tim Post
źródło
Czy kiedykolwiek miałeś problemy z plikami cookie? Na przykład, jeśli plik cookie jest tworzony na stronie www.example.com, czy możesz go odczytać z witryny bezpieczne.example.com?
Mark Henderson
@Farseeker: Możesz ustawić plik cookie dla .example.com(lub example.com, który jest taki sam), i będzie on działał zarówno dla www.example.com, jak i secure.example.com (z tą wadą, że zawsze będzie wysyłany do obu subdomen) . Oto moja ulubiona strona na ten temat: code.google.com/p/browsersec/wiki/…
Chris Lercher
@Farseeker - Tak, pliki cookie rozprzestrzeniają się do subdomen, jednak jeśli jesteś choć odrobinę sprytny, nie stanowi to problemu. Na przykład cookie-> logged_in / connection-> ssl itp. To nie jest jak CDN, gdzie ich brak jest korzystny, po prostu trzeba je zaplanować i zarządzać.
Tim Post
@Chris, nie byłem świadomy można ustawić ciasteczko dla example.comod www.example.com- będę musiał patrzeć na to. Dzięki.
Mark Henderson
Dzięki temu rozwiązaniu możesz również odmówić bezpiecznego.example.com w pliku robots.txt. Więc +1. :-)
fwaechter
3

Osobiście korzystam tylko z certyfikatu SSL Plus DigiCert z przykladami.com i www.example.com. Tak jak w drugim pytaniu, nadal wysyłam wszystkich na www.example.com, ponieważ ułatwia to później życie. Zrobienie tego teraz pozwoli również na późniejsze użycie czegoś takiego jak secure.example.com.

Zazwyczaj dodaję kod, aby wykryć, czy użytkownicy używają protokołu HTTP, kiedy powinni uruchomić HTTPS, i przekierować ich. Uważam, że zwykle dzieje się to tylko podczas logowania, ale w zależności od strony może się to zdarzyć także w innych przypadkach.

Darryl Hein
źródło