Klient

På socket-niveau er klienten den aktive part, der åbner forbindelsen. Med Berkeley/POSIX-sockets kalder en TCP-klient socket() og connect(); kernen vælger en flygtig (ephemeral) kildeport og sender en SYN til serverens adresse og port, mens serveren har kaldt bind(), listen() og accept() og venter passivt. Forbindelsen identificeres af 5-tuplen (protokol, kilde-IP, kildeport, destinations-IP, destinationsport), og det er klientens flygtige port, der gør det muligt for én maskine at have mange samtidige forbindelser til den samme serverport. UDP har ingen forbindelse, men konventionen er den samme: Klienten sender det første datagram, og serveren svarer til den kildeadresse og -port, den så.

Rollen afgøres for hver enkelt protokoludveksling, ikke af maskinen. En reverse proxy er server over for browserne og klient over for de bagvedliggende servere; en rekursiv DNS-resolver er server for stub-resolverne på de bærbare og klient over for de autoritative navneservere; en mailserver, der videresender udgående post, optræder som SMTP-klient. I peer-to-peer-protokoller spiller hver knude begge roller. HTTP (RFC 9110) kalder det klientprogram, der sender forespørgslen, en user agent, og den User-Agent-header, det sender, er selvdeklareret og let at forfalske - brugbar til statistik, men værdiløs som grundlag for autentifikation.

Hvem der tager initiativet, har direkte sikkerhedsmæssige konsekvenser. Stateful firewalls og NAT tillader normalt udgående forbindelser og svarene på dem, men afviser uopfordret indgående trafik, og derfor opfører malware sig bevidst som klient: Reverse shells og command-and-control-implantater kalder udad over HTTPS eller DNS for at komme forbi en perimeter, der ville blokere en indgående forbindelse. Server-side request forgery (SSRF, OWASP Top 10:2021 A10) er spejlbilledet, hvor angriberen får en server til ubevidst at optræde som klient over for interne systemer. Klientsoftware er desuden en stor angrebsflade i sig selv: Browsere, mailklienter, PDF-læsere og VPN-klienter fortolker data, der kommer fra servere, og en ondsindet eller kompromitteret server kan udnytte fejl i den fortolkning.

Den grundlæggende designregel er, at en server aldrig må stole på klienten. Inputvalidering, prisberegning eller adgangskontrol, der kun ligger i JavaScript eller i en mobilapp, kan omgås med en modificeret klient eller en opsnappende proxy og skal derfor håndhæves igen på serveren. I almindelig TLS er det kun serveren, der autentificeres; klienten beviser sin identitet i applikationslaget med adgangskoder eller tokens eller, ved mutual TLS, med sit eget X.509-certifikat. I driften handler styring af klienter om at holde dem patchede, have overblik over den klientsoftware, der er i brug (CIS Controls v8, Control 2), og i Zero Trust-arkitekturer at kontrollere enhedens tilstand, før klienten får lov at nå en tjeneste.