Ko nozīmē tīmekļa mitināšana - drošie mitināšanas pakalpojumi jūsu vietnei?

Draugs uzstāj, ka tā ir, ka gan pārlūkam, gan serverim ir nepieciešami sertifikāti. Es saku, ka nē, tikai serverim ir nepieciešama viena, ar divām atslēgām. Jautājums ir par to, vai pārlūks šifrēšanai SSL / TLS komunos ar serveri izmanto kaut kādu sertifikātu (ne tikai atslēgu).

  • Ņemot vērā to, ka šeit sniegtās atbildes ļoti atšķiras tehniski un kontekstā (t.i., parastā pārlūka darbība vai nē), iesaku pajautāt vietnē security.stackexchange.com, ja vēlaties gūt labāku priekšstatu par problēmu. Īsāk sakot: parastajā gadījumā klientam visvairāk nepieciešami sertifikāti. Bet ir gadījumi, kad klientam nav nepieciešami sertifikāti. Ir pat gadījumi, kad serverī nav nepieciešami sertifikāti.
  • 4 Šis ir ļoti neskaidrs jautājums. Vai jūs jautājat, vai pārlūks nepieciešama kāda sertifikāta kopija (piemēram, uzticama CA sakne), vai tā ir pieder savs sertifikāts (klienta identifikācija nosūtīta uz serveri)?

Jūsu draugs ir pareizs. Pārlūkprogrammai ir jābūt saknes sertificēšanas iestādes sertifikātam, lai tā varētu pārbaudīt, vai servera sertifikātu ir parakstījusi likumīga sertifikācijas iestāde.

  • 5 @ JörgWMittag: Jautājums nav īpaši uzdots par klienta sertifikātiem, bet gan par klientu pusē sertifikāti, t.i., klienta pusē nepieciešamie sertifikāti. Šī atbilde pareizi saka, ka klienta pusē ir nepieciešami sertifikāti: CA sertifikāti, kas tiek izmantoti kā uzticamības enkurs. Tā kā šie CA sertifikāti jau tiek piegādāti kopā ar jūsu OS un / vai pārlūku, tas darbojas jums, neinstalējot papildu sertifikātus. Tādējādi atbilde šeit nav nepareiza, tā nav tik detalizēta.
  • 5 @muru Nē, tas labi darbojas tikai ar pašparakstītiem CA sertifikātiem, ja pārlūkprogrammā instalējat savu saknes CA sertifikātu. Pretējā gadījumā tas šifrē, bet ne autentificē serveri, kas nedarbojas labi; tas ir milzīgs drošības risks.
  • 2 @muru Curl nepieciešama saknes sertifikātu pakete SSL, jā. Skatiet šeit: curl.haxx.se/docs/sslcerts.html
  • 2 @muru Jā, bet opcija "-k" liek čokurošanās nedarboties pareizi. Ir iemesls, kāpēc to sauc arī --insecure. Tas šifrēs, bet netiks autentificēts, un tas nav droši.
  • 3 @muru: teorētiski jūs varētu izmantot SSL / TLS bez sertifikātiem nevienā pusē, t.i., bez autentifikācijas vai bez sertifikātiem autentifikācijas, piemēram, SRP vai PSK. Jūs varētu arī izmantot sertifikātu servera pusē un vienkārši pārbaudīt pirksta nospiedumu klienta pusē. Bet praktiski visos gadījumos, kas attiecas uz tīmekļa meistariem, klienta pusē ir nepieciešama CA, lai pārbaudītu servera sertifikātu. Lai iegūtu sīkāku informāciju, es iesaku tos apspriest vietnē security.stackexchange.com, jo ​​šis ir piemērotāks forums, apspriežot TLS drošību ārpus parastā pārlūka gadījuma.

Tipisks uzticamas puses izsniegtu sertifikātu gadījums (šifrēsim utt.)

Servera sertifikāti ir ļoti svarīgi, jo klientam ir jāpārbauda, ​​vai viņš runā ar gaidīto serveri, lai atklātu cilvēku vidējā uzbrukumā. Lai autentificētos pret klientu, serverim ir nepieciešams pats sertifikāts, kas ir publisks, un privātā atslēga, kas atbilst sertifikātam, kuru zina tikai serveris. Lai pieņemtu servera sniegto sertifikātu kā uzticamu, klients cita starpā pārbauda, ​​vai šo sertifikātu ir izsniegusi uzticama puse, t.i., uzticama SI (CA nozīmē sertifikāta iestādi, t.i., subjektu, kas izsniedz sertifikātus). Šīs uzticamās CA tiek glabātas kā sertifikāti klientu operētājsistēmas vai pārlūkprogrammas uzticamības veikalā. Tie ir klienta pusē nepieciešamie sertifikāti.

Tad ir klienta sertifikāti, kurus izmanto klienta autentificēšanai pret serveri. Tie nav obligāti un tiek izmantoti tikai reti. Ja tie tiek izmantoti, klientam ir nepieciešams ne tikai pats (publiskais) sertifikāts, bet arī atbilstošā slepenā privātā atslēga, līdzīgi kā serverim nepieciešams, lai autentificētos pret klientu.

Retāk pašparakstītu servera sertifikātu gadījums

Šajā gadījumā serveris nosūta sertifikātu, kuru nav izsniegusi pārlūkprogrammai (vai lietotnei vai citam klientam) zināma CA. Šajā gadījumā klienta pusē sertifikāts nav iesaistīts, bet klientam jāatrod cits veids, kā pārbaudīt, vai sertifikāts ir gaidītais. Parasti pārlūkprogramma šajā gadījumā lūdz lietotāju pievienot izņēmumu.

Vēl retāk gadījums, kad sertifikātu vispār nav

SSL / TLS var izmantot arī bez sertifikātiem, t.i., pat ne servera pusē. Šajā gadījumā autentifikācija tiek veikta ar citām metodēm, piemēram, slepeno atslēgu, kas iepriekš koplietota starp klientu un serveri (PSK). Šīs metodes tiek reti izmantotas, un pārlūkprogrammas tās neatbalsta.

Apskatīsim, kas notiek starp serveri un klientu ar SSL. No Vikipēdijas:

[T] hey sarunas par valstisku savienojumu, izmantojot rokasspiediena procedūru. [...] Šīs rokasspiediena laikā klients un serveris vienojas par dažādiem parametriem, kas tiek izmantoti savienojuma drošības noteikšanai:

  • Rokasspiediens sākas, kad klients izveido savienojumu ar TLS iespējotu serveri, kas pieprasa drošu savienojumu, un klients uzrāda atbalstīto šifru komplektu (šifru un jaucējfunkciju) sarakstu.
  • No šī saraksta serveris izvēlas šifru un jaucējfunkciju, ko tas atbalsta un paziņo klientam par lēmumu.
  • Tad serveris parasti nosūta savu identifikāciju digitālā sertifikāta veidā. Sertifikātā ir servera nosaukums, uzticama sertifikāta iestāde (CA), kas garantē sertifikāta autentiskumu, un servera publiskā šifrēšanas atslēga.
  • Pirms turpināt, klients apstiprina sertifikāta derīgumu.
  • Lai ģenerētu drošajam savienojumam izmantotās sesijas atslēgas, klients vai nu:
    • šifrē nejaušu skaitli ar servera publisko atslēgu un nosūta rezultātu serverim (kuru tikai serverim vajadzētu būt iespējai atšifrēt ar savu privāto atslēgu); Pēc tam abas puses izmanto nejaušo skaitli, lai ģenerētu unikālu sesijas atslēgu sekojošai datu šifrēšanai un atšifrēšanai sesijas laikā
    • izmanto Diffie-Hellman atslēgu apmaiņu, lai droši ģenerētu nejaušu un unikālu šifrēšanas un atšifrēšanas sesijas atslēgu, kurai ir papildu noslēpuma slepenības īpašība: ja servera privātā atslēga tiks atklāta nākotnē, to nevar izmantot pašreizējās sesijas atšifrēšanai, pat ja sesiju pārtver un reģistrē trešā puse.

Tas beidz rokasspiedienu un sāk drošu savienojumu, kas tiek šifrēts un atšifrēts ar sesijas atslēgu, līdz savienojums tiek aizvērts.

Nevienā brīdī to nedara serveris lūgt klientam sertifikātu. Parasti 4. darbībā (apliecinot sertifikāta derīgumu) klients izmanto vietējo CA sertifikātu krātuvi, lai pārbaudītu, vai servera iesniegtā sertifikātu ķēde ir derīga. Tomēr klientam ir pilnīgi iespējams izmantot kādu citu metodi. Piemēram, tas notiek ar pašparakstītiem sertifikātiem: pārlūkprogramma jums jautās, vai vēlaties pieņemt šo sertifikātu, kuru nevar pārbaudīt, un, ja apstiprināt, tas ar prieku turpina pabeigt rokasspiedienu. Komandrindas klientiem patīk curl un wget ir iespējas norādīt, ka nevēlaties verificēt sertifikātu ķēdi.

Klientam nav nepieciešami sertifikāti, taču tā ir laba prakse, lai pārbaudītu, kas ir serveris, un tas nozīmē, ka klientam ir nepieciešami CA sertifikāti, lai pārbaudītu servera uzrādīto sertifikātu ķēdi.

Serveri ir iespējams konfigurēt tā, lai tas pieprasītu klienta autentifikācijas sertifikātu. Ilustrāciju skatiet šajā MSDN ierakstā.

  • Tas ir atkarīgs no jūsu definīcijas "pieprasīt". Lai izveidotu drošus un netveramus savienojumus, klienta pusē ir nepieciešami saknes CA sertifikāti, ko lielākā daļa cilvēku sagaidīs no SSL. Daļu SSL protokola varat izmantot, lai iegūtu šifrētus, bet nedrošus savienojumus, taču tas īsti neizmanto SSL paredzētajam mērķim.
  • @MikeScott šifrēšana bez autentifikācijas var būt bezjēdzīga, jā, bet tas atkal ir atkarīgs no lietošanas gadījuma. Piemēram, lielākā daļa cilvēku, kas izmanto SSH (nav jāsaprot ar SSL), nekad faktiski nepārbauda servera pirkstu nospiedumus. Un neapšaubāmi, ka tas arī neizmanto SSH paredzētajam mērķim. "Paredzētais mērķis" ir galvenokārt bezjēdzīgs termins, runājot par to, kas notiek patiesībā, un patiesībā notiek tas, ka daudzi cilvēki arī izmanto SSL, nepārbaudot uzrādītos sertifikātus.
  • Es domāju, ka galvenā problēma šeit ir tā, ka pastāv SSL / TLS, jo lielākā daļa to izmanto (ar CA izsniegtiem sertifikātiem) un SSL / TLS, kā to var arī izmantot (pašparakstīts bez CA, bez SRP servera sertifikātiem, PSK vai None autentifikācijas metode). Un dažādas atbildes šeit attiecas uz dažādiem SSL uzskatiem: bieži lietotais gadījums salīdzinājumā ar neparastu, bet tehnisku arī pareizu gadījumu.
  • @SteffenUllrich tiešām, jā. Šķiet, ka jautājums ir par strīda izšķiršanu, tāpēc tas ir atkarīgs no tā, vai OP draugs samierināsies ar tehniski pareizu vs labāko praksi.
  • 1 @muru Daudz un daudz SMTP STARTTLS ir šifrēti, bet nav autentificēti, un tas ir labi. Daudziem (bet ne visiem) draudu modeļiem pat neautentificēta, labāko pūļu, oportūnistiskā šifrēšana izslēdz dzīvās dienasgaismas datu pārsūtīšana vienkāršā tekstā, jo tas ļoti samazina pasīvās noklausīšanās vērtību. Protams, tehniskā nozīmē uzbrucējs var vienkārši novērst oportūnistisku jaunināšanu uz TLS, bet tas piespiež uzbrucēju kļūt aktīvam. Daudzi uzbrucēji nevēlas vai pat nespēj būt aktīvi.

TLS var darboties bez jebkāda "TLS" sertifikāta (ka patiesībā tas patiešām ir X.509 sertifikāts), tas ir ortogonāls. Vienam galapunktam var būt sertifikāts vai abi, vai arī neviens. TLS sniedz dažādas priekšrocības, autentifikācija ir tikai viena no tām (bet patiesībā vissvarīgākā, nevis konfidencialitāte, kas bieži vien ir pretrunīga)

strādāja par jums: Charles Robertson | Vēlies ar mums sazināties?