en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Veiledning til TLS Standards Compliance

Transportlagets sikkerhet (TLS) protokoll er det viktigste middel for å beskytte nettverkskommunikasjon over Internett. Denne artikkelen er en kort guide som hjelper deg med å konfigurere en sikker server for å møte gjeldende TLS standarder.

Introduksjon

De Transportlagsikkerhet (TLS) protokoll er det primære middel for å beskytte nettverkskommunikasjon over Internett. Den (og forgjengeren, Secure Sockets Layer eller SSL) har blitt brukt i flere tiår i mange applikasjoner, men spesielt i nettlesere når de besøker HTTPS nettsteder. TLS fungerer vanligvis stille i bakgrunnen, men i motsetning til hva man kan tro, TLS er ikke en svart boks som bare fungerer. Snarere sikkerheten TLS gir oppstår fra samarbeid med forskjellige kryptografiske algoritmer. Dessuten, TLS, som SSL før det, utvikler seg kontinuerlig med sikkerhetsindustrien - ny teknologi og forretningskrav må oppfylles, mens de siste sikkerhetstruslene må avbøtes. Algoritmer kan bli foreldet over tid, eller praksis kan forlates, med hver endring som påvirker den generelle sikkerheten til a TLS forekomst (som den som beskytter forbindelsen din akkurat nå).

Denne volatiliteten har motivert ulike standardiseringsorganisasjoner til å publisere retningslinjedokumenter, slik at et minimum baseline for TLS sikkerhet kan etableres i et bestemt marked, sektor eller tjeneste. Dessverre er det mange slike standarder, med forskjellige sektorer som krever samsvar med forskjellige, gjeldende dokumenter, mens standardene selv også utvikle seg over tid og imøtekomme endringer i sektoren de var designet for å beskytte.

Forståelig nok, å navigere gjennom dette havet av standarder for å sette opp et moderne TLS forekomst kan være en virkelig hodepine for administratorer. Denne artikkelen er en kort guide som hjelper deg med å konfigurere en sikker server for å oppfylle forventet TLS standarder i 2021. (For ytterligere hjelp har vi også gitt eksempelkonfigurasjoner av de mest populære webserverløsninger i blindtarm.)

Standarden

Det er flere enheter som opprettholder retningslinjer for TLS med hensyn til nettverkssikkerhet, for eksempel United States Department of Health and Human Services (HHS) eller National Institute of Standards and Technology (NIST). For korthets skyld vil denne artikkelen bare studere de tre mest adopterte dokumentene:

  1. De Helseforsikringsportabilitet og ansvarlig lov (HIPAA)
  2. NIST sin Retningslinjer for SP 800-52r2
  3. De Betalingskort Bransjens datasikkerhetsstandard (PCI-DSS)

HIPAA

HIPAA er en forskrift vedtatt av den amerikanske regjeringen i 1996, om sikker håndtering av Beskyttet helseinformasjon (PHI). PHI refererer til all digital pasientinformasjon, for eksempel testresultater eller diagnoser. EN HIPAA veiledningsdokument publisert i 2013 heter det følgende:

Gyldige krypteringsprosesser for data i bevegelse er de som, i det omfang det er aktuelt, overholder NIST Special Publications 800-52, Retningslinjer for valg og bruk av Transport Layer Security (TLS) Implementeringer; 800-77, guide til IPsec VPN; eller 800-113, Guide to SSL VPNs, eller andre som er Federal Information Processing Standards (FIPS) 140-2 validert.

NIST-standarder

I 2005 ga NIST ut spesiell publikasjon (SP) 800-52, og beskrev de korrekte driftsprosedyrene for å konfigurere en TLS eksempel for offentlige servere. SP 800-52 har siden blitt erstattet av versjoner SP 800-52r1 (2014) og SP 80052r2 (2019). Denne artikkelen følger retningslinjene i SP 800-52r2, som for tiden er stabil.

PCI-DSS

PCI-DSS er en samsvarsstandard som opprettholdes av Payment Card Industry (PCI) Standards Security Council (SSC) som fastslår hvordan betaling og kortinformasjon håndteres av nettsteder for e-handel. Angående riktig konfigurasjon av TLS forekomster, sier PCI-DSS:

"Se industristandarder og beste praksis for informasjon om sterk kryptografi og sikre protokoller (f.eks. NIST SP 800-52 og SP 800-57, OWASP, etc.)"

TLS standarder: å sette disse sammen

Det skal bemerkes nå at hver standard påvirker forskjellige systemer, basert på deres funksjon og dataene de håndterer. For eksempel kan en e-postserver på sykehus falle inn under HIPAA-retningslinjene fordi utvekslede meldinger kan inneholde pasientinformasjon, mens sykehusets CRM-system kan falle inn under PCI-DSS fordi det kan inneholde kredittkort og andre kundedata. Å være i samsvar med alle tre standardene vil kreve bruk av felles TLS parametere som er til stede i alle dokumentene.

Heldigvis er det åpenbart at alle standarder følger NISTs retningslinjer for valg av TLS parametre. Dette betyr at i samsvar med SP 800-52r2, i samsvar med dette skrivingen, også bør være en server kompatibel med HIPAA og PCI-DSS. (Ok, dette er det ikke nøyaktig sant, men ting vil bli tydeligere i neste avsnitt.)

konfigurerbar TLS parametere

Nivået på sikkerhet det TLS gir påvirkes mest av protokollversjon (dvs. 1.0, 1.1 osv.) og det tillatte chiffer suiter. Chiphers er algoritmer som utfører kryptering og dekryptering. Imidlertid a chiffer suite er et sett med algoritmer, inkludert en chiffer, en nøkkelutvekslingsalgoritme og en hashingsalgoritme, som brukes sammen for å etablere en sikker TLS forbindelse. Mest TLS klienter og servere støtter flere alternativer, så de må forhandle når de etablerer en sikker forbindelse for å velge en felles TLS versjon og chiffer-pakke.

TLS protokollversjon

Angående TLS versjonsstøtte, NIST SP 800-52r2 sier følgende:

Servere som støtter kun applikasjoner fra myndighetene skal konfigureres til å bruke TLS 1.2 og bør konfigureres til å bruke TLS 1.3 også. Disse serverne burde ikke konfigureres til å bruke TLS 1.1 og skal ikke bruke TLS 1.0, SSL 3.0 eller SSL 2.0.

...

Servere som støtter borger- eller forretningsapplikasjoner (dvs. at klienten kanskje ikke er en del av et offentlig IT-system) skal være konfigurert til å forhandle TLS 1.2 og bør være konfigurert til å forhandle TLS 1.3. Bruken av TLS versjoner 1.1 og 1.0 frarådes vanligvis, men disse versjonene kan konfigureres når det er nødvendig for å muliggjøre samhandling med borgere og bedrifter ... Disse serverne skal ikke tillate bruk av SSL 2.0 eller SSL 3.0.

byråer skal støtte TLS 1.3 innen 1. januar 2024. Etter denne datoen servere skal støtte TLS 1.3 for både offentlige myndigheter og applikasjoner som retter seg mot borger eller virksomhet. Generelt servere som støtter TLS 1.3 bør konfigureres til å bruke TLS 1.2 også. Men, TLS 1.2 kan være deaktivert på servere som støtter TLS 1.3 hvis det er bestemt at TLS 1.2 er ikke nødvendig for interoperabilitet.

Samtidig som TLS 1.0 er forbudt og TLS 1.1 er avskrevet for myndigheters nettsteder. NIST-retningslinjene sier at for kompatibilitet med tredjeparts tjenester, myndighetskontrollerte servere kan iverksette TLS 1.0 og 1.1 når det er nødvendig. Under PCI-DSS 3.2.1 (den nåværende versjonen), kompatible servere må droppe støtte forum TLS 1.0 og “migrere til et minimum av TLS 1.1, fortrinnsvis TLS 1.2. ” HIPAA tillater teknisk bruk av alle versjoner av TLS. Dermed det minimum som ofte støttes TLS versjon er 1.1; Imidlertid foreslår PCI-DSS og NIST sterkt bruk av de sikrere TLS 1.2 (og, som vist ovenfor, anbefaler NIST adopsjon av TLS 1.3 og planlegger å kreve støtte innen 2024).

Cipher-suiter

TLS 1.2 og tidligere

SP 800-52r2 spesifiserer en rekke akseptable krypteringssuiter for TLS 1.2 og tidligere. Standarden krever ikke støtte for noen spesifikke krypteringssuiter, men gir veiledning om valg av sterkere:

  1. Foretrekker kortvarige taster fremfor statiske nøkler (dvs. foretrekker DHE fremfor DH, og foretrekker ECDHE fremfor ECDH). Kortvarige nøkler gir perfekt fremoverhemmelighet.
  2. Foretrekk GCM- eller CCM-modus fremfor CBC-modus. Bruken av en autentisert krypteringsmodus forhindrer flere angrep (se avsnitt 3.3.2 [i SP 800-52r2] for mer informasjon). Merk at disse ikke er tilgjengelige i versjoner før TLS 1.2.
  3. Foretrekk CCM fremfor CCM_8. Sistnevnte inneholder en kortere autentiseringsmerke, som gir lavere autentiseringsstyrke.

Videre, selv om disse er tillates chiffer suiter, hvis din TLS serveren ikke har å gjøre med et stort utvalg av forskjellige plattformer og klienter, det anbefales at bare en liten undergruppe av disse algoritmene brukes. Å tillate flere chiffer-suiter kan bare utvide angrepsflaten til serveren din hvis (eller når) en ny protokollsårbarhet blir oppdaget.

Cipher Suites for ECDSA-sertifikater
TLS 1.2:
IANAVerdiOpenSSL
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA2560xC0, 0x2BECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA3840xC0, 0x2CECDHE-ECDSA-AES256-GCM-SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CCM0xC0, 0xACECDHE-ECDSA-AES128-CCM
TLS_ECDHE_ECDSA_WITH_AES_256_CCM0xC0, 0xAD ECDHE-ECDSA-AES256-CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_80xC0, 0xAEECDHE-ECDSA-AES128-CCM8
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_80xC0, 0xAFECDHE-ECDSA-AES256-CCM8
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA2560xC0, 0x23ECDHE-ECDSA-AES128-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA3840xC0, 0x24ECDHE-ECDSA-AES256-SHA384
TLS 1.2, 1.1 eller 1.0:
IANAVerdiOpenSSL
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA0xC0, 0x09ECDHE-ECDSA-AES128-SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA0xC0, 0x0AECDHE-ECDSA-AES256-SHA
Cipher Suites for RSA-sertifikater
TLS 1.2:
IANAVerdiOpenSSL
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA2560xC0, 0x2FECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA3840xC0, 0x30ECDHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA2560x00, 0x9EDHE-RSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA3840x00, 0x9FDHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_128_CCM0xC0, 0x9EDHE-RSA-AES128-CCM
TLS_DHE_RSA_WITH_AES_256_CCM0xC0, 0x9FDHE-RSA-AES256-CCM
TLS_DHE_RSA_WITH_AES_128_CCM_80xC0, 0xA2DHE-RSA-AES128-CCM8
TLS_DHE_RSA_WITH_AES_256_CCM_80xC0, 0xA3DHE-RSA-AES256-CCM8
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA2560xC0, 0x27ECDHE-RSA-AES128-SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA3840xC0, 0x28ECDHE-RSA-AES256-SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA2560x00, 0x67DHE-RSA-AES128-SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA2560x00, 0x6BDHE-RSA-AES256-SHA256
TLS 1.2, 1.1 eller 1.0:
IANAVerdiOpenSSL
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA0xC0, 0x13ECDHE-RSA-AES128-SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA0xC0, 0x14ECDHE-RSA-AES256-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA0x00, 0x33DHE-RSA-AES128-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA0x00, 0x39DHE-RSA-AES256-SHA
Cipher Suites for ECDSA-sertifikater
TLS 1.2:
IANAVerdiOpenSSL
TLS_DHE_DSS_WITH_AES_128_GCM_SHA2560x00, 0xA2DHE-DSS-AES128-GCM-SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA3840x00, 0xA3DHE-DSS-AES256-GCM-SHA384
TLS_DHE_DSS_WITH_AES_128_CBC_SHA2560x00, 0x40DHE-DSS-AES128-SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA2560x00, 0x6ADHE-DSS-AES256-SHA256
TLS 1.2, 1.1 eller 1.0:
IANAVerdiOpenSSL
TLS_DHE_DSS_WITH_AES_128_CBC_SHA0x00, 0x32DHE-DSS-AES128-SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA0x00, 0x38DHE-DSS-AES256-SHA
Cipher Suites for DH-sertifikater
DSA-signert, TLS 1.2:
IANAVerdiOpenSSL
TLS_DH_DSS_WITH_AES_128_GCM_SHA2560x00, 0xA4DH-DSS-AES128-GCM-SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA3840x00, 0xA5DH-DSS-AES256-GCM-SHA384
TLS_DH_DSS_WITH_AES_128_CBC_SHA2560x00, 0x3EDH-DSS-AES128-SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA2560x00, 0x68DH-DSS-AES256-SHA256
DSA-signert, TLS 1.2, 1.1 eller 1.0:
IANAVerdiOpenSSL
TLS_DH_DSS_WITH_AES_128_CBC_SHA0x00, 0x30DH-DSS-AES128-SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA0x00, 0x36DH-DSS-AES256-SHA
RSA-signert, TLS 1.2:
IANAVerdiOpenSSL
TLS_DH_RSA_WITH_AES_128_GCM_SHA2560x00, 0xA0DH-RSA-AES128-GCM-SHA256
TLS_DH_RSA_WITH_AES_256_GCM_SHA3840x00, 0xA1DH-RSA-AES256-GCM-SHA384
TLS_DH_RSA_WITH_AES_128_CBC_SHA2560x00, 0x3FDH-RSA-AES128-SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA2560x00, 0x69DH-RSA-AES256-SHA256
RSA-signert, TLS 1.2, 1.1 eller 1.0:
IANAVerdiOpenSSL
TLS_DH_RSA_WITH_AES_128_CBC_SHA0x00, 0x31DH-RSA-AES128-SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA0x00, 0x37DH-RSA-AES256-SHA
Cipher Suites for ECDH-sertifikater
ECDSA-signert, TLS 1.2:
IANAVerdiOpenSSL
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA2560xC0, 0x2DECDH-ECDSA-AES128-GCM-SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA3840xC0, 0x2EECDH-ECDSA-AES256-GCM-SHA384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA2560xC0, 0x25ECDH-ECDSA-AES128-SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA3840xC0, 0x26ECDH-ECDSA-AES256-SHA384
ECDSA-signert, TLS 1.2, 1.1 eller 1.0:
IANAVerdiOpenSSL
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA0xC0, 0x04ECDH-ECDSA-AES128-SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA0xC0, 0x05ECDH-ECDSA-AES256-SHA
RSA-signert, TLS 1.2:
IANAVerdiOpenSSL
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA2560xC0, 0x31ECDH-RSA-AES128-GCM-SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA3840xC0, 0x32ECDH-RSA-AES256-GCM-SHA384
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA2560xC0, 0x29ECDH-RSA-AES128-SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA3840xC0, 0x2AECDH-RSA-AES256-SHA384
RSA-signert, TLS 1.2, 1.1 eller 1.0:
IANAVerdiOpenSSL
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA0xC0, 0x0EECDH-RSA-AES128-SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA0xC0, 0x0FECDH-RSA-AES256-SHA

TLS 1.3

TLS 1.3 har en mye kortere liste over krypteringssuiter:

  • TLS_AES_128_GCM_SHA256 (0x13, 0x01)
  • TLS_AES_256_GCM_SHA384 (0x13, 0x02)
  • TLS_AES_128_CCM_SHA256 (0x13, 0x04)
  • TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

konklusjonen

Vi håper denne korte guiden vil hjelpe deg å forstå mer om TLS, og hjelpe deg når du konfigurerer TLS på din egen server. Med hensyn til standardene og anbefalingene vi har diskutert, inneholder følgende avsnitt et eksempel på konfigurasjon som du bør kunne bruke på de mest populære webserverløsningene. Hvis du har spørsmål om hvordan du opprettholder din online samsvar, kan du gjerne kontakte oss via e-post Support@SSL.com eller klikke på live chat-knappen nederst på dette skjermbildet.

Vedlegg: Eksempel TLS konfigurasjoner

Innsamling av reglene som er angitt i de tre spesifikasjonsdokumentene, bør en moderne sikker server implementere TLS 1.2 og / eller TLS 1.3, med en kort, men mangfoldig liste over utvalgte krypteringssuiter. Som en hurtigreferanse vises eksempelkonfigurasjoner for de mest populære webserverne i markedet nedenfor. Dette er "mellomliggende" (generelle) konfigurasjoner generert med Mozillas SSL-konfigurasjonsgenerator:

ApacheNginxlighttpdHAProxyAWS ELB

Apache HTTP-server

... SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384D: ECDH POLY20: ECDHE-RSA-CHACHA1305-POLY20: DHE-RSA-AES1305-GCM-SHA128: DHE-RSA-AES256-GCM-SHA256 SSLHonorCipherBestill av SSLSessionBilletter av

Nginx

... ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

lighttpd

... ssl.openssl.ssl-conf-cmd = ("Protocol" => "ALL, -SSLv2, -SSLv3, -TLSv1, -TLSv1.1 ") ssl.cipher-list =" ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM- SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 "ssl.honor-cipher-order ="

HAProxy

...

ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options foretrekker-client-chifre no-sslv3 no-tlsv10 nei-tlsv11 nei-tls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-server-options no-sslv3 no-tlsv10 nei-tlsv11 nei-tls-Billetter

AWS ELB

... Politikk: - PolicyName: Mozilla-intermediate-v5-0 PolicyType: SSLNegotiationPolicyType Attributter: - Navn: Protocol-TLSv1.2 Verdi: true - Navn: Server-Defined-Cipher-Order Value: false - Navn: ECDHE-ECDSA-AES128-GCM-SHA256 Verdi: true - Navn: ECDHE-RSA-AES128-GCM-SHA256 Verdi: true - Navn: ECDHE-ECDSA-AES256-GCM-SHA384 Verdi: true - Navn: ECDHE-RSA-AES256-GCM-SHA384 Verdi: true - Navn: DHE-RSA-AES128-GCM-SHA256 Verdi: true - Navn: DHE-RSA -AES256-GCM-SHA384 Verdi: sant

Trenger du et sertifikat? SSL.com tilbyr et bredt utvalg av digitale sertifikater, inkludert:

SAMMENLIGN SSL /TLS SERTIFIKATER

Del på twitter
Twitter
Del på facebook
Facebook
Del på linkedin
Linkedin
Del på reddit
Reddit
Del på e-post
E-post