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:
IANA Verdi OpenSSL
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 0xC0, 0x2B ECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 0xC0, 0x2C ECDHE-ECDSA-AES256-GCM-SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CCM 0xC0, 0xAC ECDHE-ECDSA-AES128-CCM
TLS_ECDHE_ECDSA_WITH_AES_256_CCM 0xC0, 0xAD ECDHE-ECDSA-AES256-CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 0xC0, 0xAE ECDHE-ECDSA-AES128-CCM8
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 0xC0, 0xAF ECDHE-ECDSA-AES256-CCM8
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 0xC0, 0x23 ECDHE-ECDSA-AES128-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 0xC0, 0x24 ECDHE-ECDSA-AES256-SHA384
TLS 1.2, 1.1 eller 1.0:
IANA Verdi OpenSSL
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0xC0, 0x09 ECDHE-ECDSA-AES128-SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0xC0, 0x0A ECDHE-ECDSA-AES256-SHA
Cipher Suites for RSA-sertifikater
TLS 1.2:
IANA Verdi OpenSSL
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC0, 0x2F ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC0, 0x30 ECDHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 0x00, 0x9E DHE-RSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 0x00, 0x9F DHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_128_CCM 0xC0, 0x9E DHE-RSA-AES128-CCM
TLS_DHE_RSA_WITH_AES_256_CCM 0xC0, 0x9F DHE-RSA-AES256-CCM
TLS_DHE_RSA_WITH_AES_128_CCM_8 0xC0, 0xA2 DHE-RSA-AES128-CCM8
TLS_DHE_RSA_WITH_AES_256_CCM_8 0xC0, 0xA3 DHE-RSA-AES256-CCM8
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 0xC0, 0x27 ECDHE-RSA-AES128-SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 0xC0, 0x28 ECDHE-RSA-AES256-SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 0x00, 0x67 DHE-RSA-AES128-SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 0x00, 0x6B DHE-RSA-AES256-SHA256
TLS 1.2, 1.1 eller 1.0:
IANA Verdi OpenSSL
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0xC0, 0x13 ECDHE-RSA-AES128-SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xC0, 0x14 ECDHE-RSA-AES256-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x00, 0x33 DHE-RSA-AES128-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0x00, 0x39 DHE-RSA-AES256-SHA
Cipher Suites for ECDSA-sertifikater
TLS 1.2:
IANA Verdi OpenSSL
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 0x00, 0xA2 DHE-DSS-AES128-GCM-SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 0x00, 0xA3 DHE-DSS-AES256-GCM-SHA384
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 0x00, 0x40 DHE-DSS-AES128-SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 0x00, 0x6A DHE-DSS-AES256-SHA256
TLS 1.2, 1.1 eller 1.0:
IANA Verdi OpenSSL
TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0x00, 0x32 DHE-DSS-AES128-SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0x00, 0x38 DHE-DSS-AES256-SHA
Cipher Suites for DH-sertifikater
DSA-signert, TLS 1.2:
IANA Verdi OpenSSL
TLS_DH_DSS_WITH_AES_128_GCM_SHA256 0x00, 0xA4 DH-DSS-AES128-GCM-SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384 0x00, 0xA5 DH-DSS-AES256-GCM-SHA384
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 0x00, 0x3E DH-DSS-AES128-SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 0x00, 0x68 DH-DSS-AES256-SHA256
DSA-signert, TLS 1.2, 1.1 eller 1.0:
IANA Verdi OpenSSL
TLS_DH_DSS_WITH_AES_128_CBC_SHA 0x00, 0x30 DH-DSS-AES128-SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA 0x00, 0x36 DH-DSS-AES256-SHA
RSA-signert, TLS 1.2:
IANA Verdi OpenSSL
TLS_DH_RSA_WITH_AES_128_GCM_SHA256 0x00, 0xA0 DH-RSA-AES128-GCM-SHA256
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 0x00, 0xA1 DH-RSA-AES256-GCM-SHA384
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 0x00, 0x3F DH-RSA-AES128-SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 0x00, 0x69 DH-RSA-AES256-SHA256
RSA-signert, TLS 1.2, 1.1 eller 1.0:
IANA Verdi OpenSSL
TLS_DH_RSA_WITH_AES_128_CBC_SHA 0x00, 0x31 DH-RSA-AES128-SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA 0x00, 0x37 DH-RSA-AES256-SHA
Cipher Suites for ECDH-sertifikater
ECDSA-signert, TLS 1.2:
IANA Verdi OpenSSL
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 0xC0, 0x2D ECDH-ECDSA-AES128-GCM-SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 0xC0, 0x2E ECDH-ECDSA-AES256-GCM-SHA384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 0xC0, 0x25 ECDH-ECDSA-AES128-SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 0xC0, 0x26 ECDH-ECDSA-AES256-SHA384
ECDSA-signert, TLS 1.2, 1.1 eller 1.0:
IANA Verdi OpenSSL
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 0xC0, 0x04 ECDH-ECDSA-AES128-SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 0xC0, 0x05 ECDH-ECDSA-AES256-SHA
RSA-signert, TLS 1.2:
IANA Verdi OpenSSL
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 0xC0, 0x31 ECDH-RSA-AES128-GCM-SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 0xC0, 0x32 ECDH-RSA-AES256-GCM-SHA384
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 0xC0, 0x29 ECDH-RSA-AES128-SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 0xC0, 0x2A ECDH-RSA-AES256-SHA384
RSA-signert, TLS 1.2, 1.1 eller 1.0:
IANA Verdi OpenSSL
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 0xC0, 0x0E ECDH-RSA-AES128-SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 0xC0, 0x0F ECDH-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

Twitter
Facebook
Linkedin
Reddit
Epost

Hold deg informert og sikker

SSL.com er en global leder innen cybersikkerhet, PKI og digitale sertifikater. Registrer deg for å motta de siste bransjenyhetene, tipsene og produktkunngjøringene fra SSL.com.

Vi vil gjerne ha tilbakemeldinger

Ta vår spørreundersøkelse og fortell oss dine tanker om ditt nylige kjøp.