Firewall and IDS/IPS What is a firewall? firewall = wall to protect - - PDF document

Firewall and IDS/IPS What is a firewall?

 firewall = wall to protect against fire propagation  controlled connection between networks at different

security levels = boundary protection

( L1 > L2 ) network at security level L2

1

network at security level L1 INTERNAL NETWORK EXTERNAL NETWORK

Ingress vs. Egress firewall

 ingress firewall  incoming connections  typically to protect my public services  sometimes as part of an application exchange

initiated by my users

 egress firewall  outgoing connections  typically to check the activity of my personnel (!)  easy classification for channel-based services (e.g.

TCP applications), but difficult for message-based services (e.g. ICMP, UDP applications)

Firewall design

Y

• u don’t “buy” a firewall, you design it!

(you can buy its components)

 we need to achieve an optimal trade-off ...  ... between security and functionality  ... with minimum cost

2

The security index

100 20 40 60 80 100 % 80 60 40 20 security functionality

THE THREE COMMANDMENTS OF FIREWALL

• I. the FW must be the only

contact point of the internal network with the external one

• II. only the “authorized” traffic

can traverse the FW

• III. the FW must be a highly

secure system itself

D.Cheswick S.Bellovin

3

Authorization policies

“All that is not explictly permitted, is forbidden”

 higher security  more difficult to manage

“All that is not explictly forbidden, is permitted”

 lower security (open gates)  more easy to manage

General concepts

 the bigger an object, the more difficult to verify it  if a process has not been activated, its bugs are not

relevant

 “big is NOT beatiful” = minimal configuration  a FW is not a general-purpose machine:  minimal sw  no users  …  everybody is guilty unless he proves his innocence

4

FW: basic components

 screening router ( choke )

router that filters traffic at IP level

 bastion host

secure system, with auditing

 application gateway ( proxy )

service that works on behalf of an application, with access control

 dual-homed gateway

system with two network cards and routing disabled

A which level the controls are made?

packet headers TCP stream UDP datagram application data

circuit gateway application gateway

transport (TCP / UDP) application

packet filter

datalink physical network (IP)

5

"Screening router" architecture

external network

"Screening router" architecture

 exploits the router to filter the traffic both at IP and

upper levels

 no need for dedicated hardware  no need for a proxy and hence no need to modify

the applications

 simple, easy, cheap and ... insecure!

6

"Dual-homed gateway" architecture

external network

GW

"Dual-homed gateway" architecture

 easy to implement  small additional hardware requirements  the internal network can be masqueraded  unflexible  large work overhead

7

"Screened host" architecture

external network

GW

"Screened-host" architecture

 router:  blocks the packets from INT to EXT unless they

come from the bastion host

 blocks the packets from EXT to INT unless they go

to the bastion host

 exception: directly enabled protocols  bastion host:  circuit/application level gateway to selectively enable

some services

8

"Screened-host" architecture

 more expensive  more flexible  complex to manage: two systems rather one  possible selectively relax the controls over some

services / hosts

 only the hosts/protocols passing through the

bastion can be masqueraded (unless the router

• ffers the NAT functionality)

"Screened subnet" architecture

external network DMZ

GW 9

"Screened subnet" architecture

 DMZ (De-Militarized Zone)  the DMZ is home not only to the gateway but also to

• ther hosts (tipically the public servers):

 Web  remote access  . . .  the routing may be configured so that the internal

network is unknown

 expensive

"Screened subnet" architecture (version 2)

 to reduce costs and simplify management often the

routers are omitted (and their function incorporated into the gateway)

 “three-legged firewall”

GW

internal network external network DMZ

10

Filters at network level (I)

 address checking (ingress / egress filtering)  disable incoming services (with exceptions):  e.g. TELNET only towards INET  e.g. incoming HTTP only to the DMZ web server  problem with FTP (the data transfer channel is

always created by the server)

 ICMP  is dangerous (used for denial-of-service) but useful

(ping, traceroute) so don’t disable it, just rate-limit it

 closely monitor REDIRECT packets

Problem with FTP across a firewall

(OK) FTP server 21 FTP client

• pen

(S,TCP ,21) put (OK) firewall 21 20 (???)

• pen

(C,TCP ,20)

11

Passive FTP

firewall FTP server 21 FTP client

• pen

(S,tcp,21) pasv port(1040)

• pen

1040 20 file (S,tcp,1040) (OK) (OK)

Filters at network level (II)

 UDP  is a datagram service, not a virtual circuit (so its

checking poses a higher load)

 RPC uses random ports  it is suggested to completely disable it (but DNS)  distinguish internal and external interfaces  pay attention to the number of filtering rules and

their order: this may drastically change performance

12

(OK) (OK) (OK)

Filtering points

firewall filter filter forwarding engine filter incoming packets

• utgoing

packets filter

Filters on a router: an example

 policy: mail for network 130.193 managed only by

130.193.2.1

 sintax of CISCO router:  access-list 100 permit tcp

0.0.0.0 255.255.255.255 130.193.2.1 0.0.0.0 eq 25

 access-list 101 deny tcp

0.0.0.0 255.255.255.255 130.193.0.0 0.0.255.255 eq 25

13

Bastion host - configuration

 should run only the relevant processes  must log (securely!) all its activities  network log onto an internal secure system  must have source routing disabled  must have IP forwarding disabled  should have “mouse traps” (e.g. fake ls)

Firewall technologies

 different controls at various network levels:  (static) packet filter  stateful (dynamic) packet filter  cutoff proxy  circuit-level gateway / proxy  application-level gateway / proxy  stateful inspection  differences in terms of:  performance  protection of the firewall O.S.  keeping or breaking the client-server model

14

Packet filter

 historically available on routers  packet inspection at network level  IP header  transport header

Packet filter: pros and cons

 independent of applications  good scalability  approximate controls: easy to “fool”

(e.g. IP spoofing, fragmented packets)

 good performance  low cost (available on routers and in many OS)  difficult to support services with dynamically

allocated ports (e.g. FTP)

 complex to configure

15

Packet filter & FTP

 two choices available:  leave open all dynamic ports (>1024)  close all dynamic ports  difficult trade-off between security and support to

FTP!!

• pen (S,tcp,21)

internal network FTP server FTP client pasv port(1040)

• pen (S,tcp,1040)

Stateful (dynamic) packet filter

 similar to packet filter but “state-aware”  state informations from the transport or application

level (e.g. FTP PORT command)

 can distinguish new connections from those already

• pen

 state tables for open connections  packets matching one row in the table are passed

without any further control

 better performance than packet filter  still has many of the static packet filter limitations

16

Application-level gateway

 composed by a set of proxies inspecting the packet

payload at application level

 often requires modifications to the client application  may optionally mask / renumber the internal IP

addresses

 when used as part of a firewal, usually performs

also peer authentication

 top security!! (e.g. against buffer overflow of the

target application)

Application-level gateway (1)

 rules are more fine-grained and simple than those of

a packet filter

 every application needs a specific proxy  delay in supporting new applications  heavy on resources (many processes)  low performance (user-mode processes)  completely breaks the client/server model  more protection for the server  may authenticate the client  not transparent to the client

17

Application-level gateway (2)

 the fw OS may be esposed to attacks  problems with application-level security techniques

(e.g. SSL)

 variants:  transparent proxy  less intrusive for the client  strong application proxy  only some commands/data are forwarded  this is the only correct configuration for an

application proxy

Application-level gateway & FTP

 total control of the application session

control connection control connection application space FTP proxy server FTP client FTP firewall OS kernel space data connection data connection 18

Circuit-level gateway (1)

 a generic proxy (i.e. not “application-aware”)  creates a transport-level circuit between client and

server …

 … but it doesn’t understand or manipulate in any

way the payload data

Circuit-level gateway (2)

 breaks the TCP/UDP-level client/server model during

the connection

 more protection for the server  isolated from all attacks related to the TCP

handshake

 isolated from all attacks related to the IP

fragmentation

 may authenticate the client  but this requires modification to the application  still exhibits many limitations of the packet filter

19

SOCKS

 a transport-level proxy (L4) that implements a

circuit-level gateway

 invented at MIPS, v4 by NEC, v5 by IETF  AFT (Authenticated Firewall Traversal)  requires modified clients:  standard: telnet, ftp, finger, whois  library to develop own clients  commercial support:  all the major browsers (e.g. FX and IE)  some firewalls (e.g. IBM)

SOCKS RFCs

 RFC-1928 “SOCKS protocol V5”  RFC-1929 “Username/password authentication for

SOCKS V5”

 RFC-1961 “GSS-API authentication method for

SOCKS V5”

 RFC-3089 “A SOCKS-based IPv6/IPv4 gateway

mechanism”

20

SOCKS: how it works

 the library replaces the standard socket system

calls connect(), bind(), accept(), ...

 ... with calls that:  open a channel to the SOCKS server  send version, IP:port, user  the server:  checks its ACL  opens the required channel (with its own IP address)

and relays L4 payloads

SOCKS: initial problems

 SOCKS v4:  doesn’t distinguish the internal and external nets  weak user authentication (based on identd or id

stored locally on client)

 supports only TCP  solution = SOCKS v5:  supports UDP too  better authentication (user+pwd or GSS-API)  encryption (between the SOCKS client and server)

21

Reverse proxy

 HTTP server acting just as a front-end for the real

server(s) which the requests are passed to

 benefits:  obfuscation (no info about the real server)  load balancer  SSL accelerator (with unprotected back-end

connections …)

 web accelerator (=cache for static content)  compression  spoon feeding (gets from the server a whole

dynamic page and feeds it to the client according to its speed, so unloading the application server)

Reverse proxy: possible configurations

external network external network internal network reverse serv1 serv2 internal network firewall DMZ reverse firewall DMZ proxy serv1 serv2 proxy VPN

22

FW architectures: which is the right one?

 theoretically, the higher the level and:  the higher the CPU cycles needed  the higher the protection level  the (sad) reality:

Firewall customers once had a vote, and voted in favor

• f transparency

, performance and convenience instead

• f security; nobody should be surprised by the results.

(Marcus J. Ranum, the “grandfather of firewalls”, firewall wizard mailing list, oct 2000)

FW architectures: which is the right one?

 the best choice:  not a single product, but a robust fw architecture that

supplements the holes and vulnerabilities of the single components!!!

 for each component choose something available on

several architectures: it’s better to be able to choose rather than leaving the choice to the vendor!!

 beware of solutions promising to solve each and

every security problem: may be it’s just advertisement …

23

Firewall: commercial products

 there is plenty of firewall manufacturers/vendors  tipically on UNIX, sometimes on Windows (the latter

requires changing the TCP/IP stack!)

 the free Firewall Toolkit (FWTK)  TIS (www.tis.com)  base application-gateway components  the free IPchains / IPfilter / IPtables on Linux  packet-filter

Linux: netfilter components

(image from wikipedia)

24

Default netfilter chains

 PREROUTING  all incoming packets, before any routing decision  INPUT  packets with destination the node itself (the "local-

delivery" routing table: "ip route show table local")

 FORWARD  packets to be forwarded, after the routing decision  OUTPUT  packets generated by the node itself  POSTROUTING  all outgoing packets, just before sending them

net card net card

Netfilter / iptables: packet flow

prerouting conntrack mangle NA T (dst) (qdisc) routing decision forward filter mangle postrouting conntrack mangle NA T (src) (qdisc) deny / reject local process input filter conntrack mangle

• utput

filter conntrack mangle NA T (dst) routing decision deny / reject deny / reject

25

Stealth firewall

 firewall without an IP address, so that it cannot be

directly attacked

 physical packet interception (by setting the

interfaces in promiscuous mode)

external network internal network stealth firewall

Local / personal firewall

 firewall directly installed at the node to be protected  typically a packet filter  w.r.t. a normal network firewall, it may limit the

programs than are allowed:

 to open network channels towards other nodes (i.e.

act as a client)

 to answer network requests (i.e. act as a server)  important to limit the diffusion of malware and

trojans, or plain configuration mistakes

 firewall management must be separated from the

system management

26

Protection offered by a firewall

 a firewall is 100% effective only for attacks

• ver/against blocked channels

 the other channels require other protection

techniques:

 VPN  “semantic” firewall / IDS  application-level security

F W

Intrusion Detection System (IDS)

 definition:  system to identify individuals using a computer or a

network without authorization

 extendable to identify authorized users violating their

privileges

 hypothesis:  the behavioural “pattern” of non-authorized users

differs from that of authorized users

27

IDS: functional features

 passive IDS:  cryptographic checksum (e.g. tripwire)  pattern matching (“attack signature”)  active IDS:  “learning” = statistical analysis of the system

behaviour

 “monitoring” = active statistical info collection of

traffic, data, sequences, actions

 “reaction” = comparison against statistical

parameters (reaction when a threshold is exceeded)

IDS: topological features

 HIDS (host-based IDS)  log analysis (OS, service or application)  internal OS monitoring tools  NIDS (network-based IDS)  network traffic monitoring tools

28

SIV and LFM

 System Integrity Verifier  checks files / filesystems looking for changes  e.g. changes to Windows registry, cron

configuration, user privileges

 e.g. tripwire  Log File Monitor  checks the log files (OS and applications)  looks for known patterns of successful attacks or

attempts

 e.g. swatch

NIDS components

 sensor  checks traffic and logs looking for suspect patterns  generated the relevant security events  interacts with the system (ACLs, TCP reset, ... )  director  coordinates the sensors  manages the security database  IDS message system  secure and reliable communication among the IDS

components

29

NIDS architecture

IDS director DMZ (host) (host) sensor(s) external network internal network

FW

(net) sensor sensor(s) (net) sensor(s)

IDS/NIDS interoperability

 much needed because the attacks involve different

• rganizations and/or are detected by different tools

 attack signature format:  no standard, but Snort format is in large use  alarm format and protocol for alarm transmission:  IDMEF + IDXP + IODEF (IETF)  SDEE (Cisco, ISS, SourceFire)

30

data source

NIDS data flow

activity analyzer sensor event notification administrator

• perator

manager alert response

security policy

IDMEF + IDXP

 developed by the IETF  Intrusion Detection Message Exchange Format  indipendent from the protocol (IPv4, IPv6)  supports internationalization and localization  supports data aggregation and filtering (on the

manager)

 Intrusion Detection eXchange Protocol  based on BEEP (RFC-3080)  profile exchange (for end-to-end security, for ID)  base security profile is TLS

31

SDEE

 Secure Device Event Exchange  based on the webservice paradigm:  messages in XML  messages transported over HTTP or HTTPS  closed standard (?), managed by the ICSAlabs

IODEF

 Incident Object Description and Exchange Format  is a superset of IDMEF  used to exchange information between different

• rganizations, keep statistics, evaluate risks, ...

32

IPS

 Intrusion Prevention System  to speed-up and automate the reaction to intrusions

= IDS + distributed dynamic firewall

 a technology, not a prudoct, with large impact on

many elements of the protection system

 dangerous! may take the wrong decision and block

innocent traffic

Honey pot

DMZ external network web server Decoy DMZ honey pot (external attacks) honey pot (internal attacks)

33

internal network trusted host

E-mail security

Electronic mail security MHS (Message Handling System)

MSA MSA MT A MT A MT A chain MS MS MUA MUA

 MUA (Message User Agent)  MSA (Message Submission Agent)  MTA (Message Transfer Agent)  MS (Message Store)

34

E-mail security

E-mail on multi-user systems

Mail User editor Mail User Agent RFC-822 Agent MSA (MT A ) Mail Transfer Agent SMTP SMTP SMTP SMTP MT A MT A MT A

E-mail in client-server mode

SMTP SMTP Mail User Agent Mailserver ( MSA ) MT A ... Post Office ( MS ) POP , IMAP ... MT A SMTP

35

E-mail security

Webmail

Mailserver ( MSA ) MT A ... SMTP web server virtual MUA SMTP HTTP engine HTTP HTML Post Office ( MS ) ... MT A SMTP web browser POP / IMAP

Protocols and ports

 SMTP (Simple Mail Transfer Protocol)  25/tcp (MTA)  587/tcp (MSA)  POP (Post Office Protocol)  110/tcp  IMAP (Internet Message Access Protocol)  143/tcp

36

E-mail security

RFC-822 messages

 only US-ASCII characters on 7 bits  messages composed by header + body  header  keywords at the beginning of the line  continuation lines start with a space  body  separated from the header by an empty line  contains the message  From:

Sender:

Header RFC-822

sender (logical) sender (operational)

• rganization of the sender

destination subject date and hour of sending intermediate steps

 Organization:  To:  Subject:  Date:  Received:

37

 Message-Id:  CC:

Bcc:

 Return-Receipt-To:

sending ID copy to copy (hidden) to return receipt to

E-mail security

Problems in securing e-mail

 connectionless system (store-and-forward)  MTA not trusted  security of MS  mailing-list  compatibility with what is already installed  concurrent solutions:  Internet = PGP, PEM, MOSS, S/MIME  OSI = X.400

Mail spamming

 also named UBE (Unsolicited Bulk Email)  sending of unauthorised advertising (publicitary)

messages

 common habits:  hide the real sender  delegate the work to do to an MTA that operates as

an “open mail relay”, that is one that accepts mail also from / to other users (not from his domain)

 heavy load on the servers and on the

communication channels

 (usually) bothers the users  risk to end up in ORB, RBL or similar

38

E-mail security

Mail relay

uqu.sa uqu.sa mail relay

How to fight spamming

 do not configure your own MTA as an “open relay”

but restrict its use only to authorized users

 authentication strategies:  IP address of the MUA  problem with the mobile users and IP spoofing  value of the field From  can be easily tricked with a fake mail  SMTP authentication  secure authentication?  SMTP on SSL with client authentication

39

E-mail security

Anti-spamming initiatives

 MAPS (Mail Abuse Prevention System)  http://maps.vix.org/  RBL (Realtime Blackhole List)  RSS (Relay Spam Stopper)  not easy to be removed once you’ve been inserted

in such a system: it becomes a ‘MUST’ to configure correctly your own MTA

 activate/use the address abuse@domain, as

required by RFC-2142

ESMTP

 Extended SMTP, defined in RFC-1869 and

subsequently incorporated (wirh SMTP) in RFC- 2821

 the base protocol and the communication channel

is the same

 the ESMTP clients must identify themselves to the

communicating parties with: EHLO hostname

 if the receiving server speaks ESMTP, it must

declare the extensions that it supports, one per line, in its response to EHLO

40

E-mail security

Standard ESMTP extensions

 8BITMIME  (RFC-1652) indicates that in the DATA part 8-bit

characters are accepted and not mangled

 SIZE dimension

MAIL FROM: address SIZE=dimension

 (RFC-1870) declares the maximum dimension

accepted by the server or the dimension of the message to be sent

 PIPELINING  (RFC-1854) sending several commands with no

need to wait for the response to each one (exception: those that provoke a status change)

DSN extension (Delivery Status Notification)

 extends the RCPT command with:  NOTIFY=notify-list

possible values: NEVER, SUCCESS, FAILURE, DELAY

 ORCPT=original-recipient

specifies the original recipient

 extends the MAIL command with:  RET=returned-message

possible values: FULL, HDRS

 ENVID=sender-id

identifier created by the sender

41

E-mail security

Positive ESMTP examples

 ESMTP mailer without extensions:

220mail.uqu.sa- SMTPserviceready EHLOmailer .x.com 250Hellomailer .x.com- nicetomeet you!

 ESMTP mailer with extensions:

220m ail.uqu.sa- SMTPserviceready EHLOmailer .x.com 250-Hellomailer .x.com- nicetomeet you! 250-EXPN 2508BITMIME

Negative ESMTP example

 the mailer does not know the ESMTP protocol:

220mail.uqu.sa- SMTPserviceready EHLOmailer .x.com 500Commandnotrecognized:EHLO

42

E-mail security

SMTP-Auth

 extension of ESMTP defined in RFC-4954  command AUTH + options of MAIL FROM  to authenticate a client …  … before accepting messages from it!!!  useful against spamming:  after the EHLO command the server sends the

authentication mechanisms supported

 the client chooses one  the authentication protocol is executed  if the authentication fails, the communication

channel is closed

Negative AUTH example

 the mailer does not know (or does not accept)

the authentication method proposed by the client: 220example.uqu.sa- SMTPserviceready EHLOmailer .x.com 250-example.uqu.sa 250A UTHLOGINCRA M-MD5DIGEST

• MD5

A UTHPLAIN 504Unrecognizedauthenticationtype

43

E-mail security

AUTH: LOGIN method

220example.uqu.sa- SMTPserviceready EHLOm ailer .x.com 250-example.uqu.sa 250A UTHLOGINCRA M-MD5DIGEST

• MD5

A UTHLOGIN

Username:

334VXNlcm5hbWU6 bGlveQ== 334UGFzc3dvcmQ6 YW50b25pbw== 235authenticated

test sample Password:

AUTH: PLAIN method

 syntax (RFC-2595):

AUTH PLAIN id_pwdBASE64

 id_pwd is defined as:

[ authorize_id ] \0 authentication_id \0 pwd 220example.uqu.sa- SMTPserviceready EHLOmailer .x.com 250-example.uqu.sa 250A UTHLOGINPLAIN A UTHPLAINbGlveQBsaW95AGFudG9uaW8= 235authenticated

test \0 lioy \0 sample

44

E-mail security

MAIL FROM with authentication

 the optional parameter AUTH of MAIL FROM

indicates who sends the message

 it is used < > to indicate an unknown identity or

not sufficiently authenticated

 allows to communicate the identity of the sender

among cooperating MTA in a trusted environment

 each MTA must propagate the identity when

sending (forwarding) the message

 possible use for authorisation policies

MAIL FROM with authentication: example

220exam ple.uqu.sa- SMTPserviceready EHLOmailer .x.com 250-example.uqu.sa 2508BITMIME MAILFROM:<has@uqu.sa>AUTH=hassal 250OK

45

E-mail security

Protection of SMTP with TLS

 RFC-2487 “SMTP Service Extension for Secure

SMTP over TLS”

 STARTTLS = option of EHLO and command  if the negotiation is succesful, the protocol status

is reset (starts again from EHLO and the extensions supported can be different)

 if the negotiated security level is insufficient:  the client sends immediately QUIT and closes the

connection

 the server responds to each command with code

554 (refused due to low security)

Protection of SMTP with TLS: example

220example.uqu.sa- SMTPserviceready EHLOmailer .x.com 250-example.uqu.sa 250-8BITMIME 250-ST ARTTLS 250DSN ST A RTTLS 220Goahead …TLSnegotiationisstartedbetweenclientandserver

46

E-mail security

Security services for e-mail messages

 integrity (without direct communication):  the message cannot be modified  authentication  identifies the sender  non repudiation  the sender cannot deny of having sent the mail  confidentiality (optional):  messages are not readable both in transit and

when stored in the mailbox

E-mail security – main ideas (I)

 no modification to the present MTA  messages encoded to avoid problems when

passing through gateways (e.g Internet-Notes) or MTA non 8BITMIME

 no modification to the present UA  inconvenient user interface  with modification to the present UA  better user interface

47

E-mail security

E-mail security – main ideas (II)

 symmetric algorithms  for the encryption of messages  with message key  asymmetric algorithms  to encrypt and exchange the symmetric key  for digital signature  use public key certificates (e.g. X.509) for non-

repudiation

 the message security is based only on the

security of the UA of the recipient, not on the security of MTA (not trusted)

Types of secure messages

 clear-signed  msg in clear (so that anybody is able to read it) +

digital signature

 only who has a secure MUA can verify the signature  signed  [ msg + dsig ] encoded (e.g. base64, uuencode)  only who has a secure MUA (or performs operations

manually) can decode and verify the signature

 encrypted / enveloped  [ encrypted msg + encrypted keys ] encoded  only who has a secure MUA (and the keys!) can

decrypt the message

 signed and enveloped

48

E-mail security

Secure messages: creation

 transform in canonical form  standard format, independent from OS / host / net  MIC (Message Integrity Code)  integrity and authentication  typically: msg + { h(msg) } Kpri_sender  encryption  confidentiality  typically: { msg } KM + { KM } Kpub_receiver  encoding  to avoid modification by the MTA  typically: base64, uuencode, binhex

Secure electronic mail formats

IETF underground DOD + EC

MOSS PEM MIME-PGP PGP X.400 X.421 S/MIME

49

E-mail security

PGP (Pretty Good Privacy)

 authentication, integrity and confidentiality for

electronic mail or private files

 same objectives as PEM and similar structure but

less structured

 peculiar way of public-key certification (trusted

"friends" and trust propagation algebra)

 RFC:  RFC-1991 (informational)  RFC-4880 (OpenPGP)  versions for UNIX, VMS, MS-DOS, Mac, Amiga, ...  the author (Phil Zimmerman) and the program

have become a symbol of the freedom in Internet

Phil Zimmermann

 releases PGP as freeware in 1991  jailed, released on bail and investigated until 1996,

when accusations are dropped and he creates PGP

• Inc. later acquired by NAI

 august 2002 leaves NAI and creates PGP Co.

50

E-mail security

PGP - algorithms

 symmetric encryption:  IDEA  digest:  MD5  asymmetric encryption (for digital signature and

symmetric key exchange):

 RSA  all free of charge for non-commercial purposes

PGP 2.6 example: signature + encryption

+ M+S IDEA B64 ZIP MD5 RSA + message M {M+S}+{KM} KM message key RSA sender’s private key receiver’s public key { KM }

51

E-mail security

PGP - certification

 each certificate has several signatures (those of

all persons that trust the key owner)

 trust is propagated transitively with some

approximation:

 completely  partially  untrusted  unknown

PGP web of trust

E F M

YOU

A B C D G I L

?

N completely trusted partially trusted untrusted unknown X Y signs X Y H

52

E-mail security

PGP – key distribution

 public-keys stored individually by each user (in its

key-ring)

 keys distributed directly by the owner (at a PGP

party!) or by a key-server (http, smtp, finger)

 projects for key distribution via X.500 or DNS

(pgp.net):

 www.pgp.net  keys.pgp.net  ftp.pgp.net

PGP & NAI

 rights of PGP acquired in december 1997 by NAI

(Network Associates Inc.)

 new version, based on DSA, DH, 3DES  integration with several MUAs  attempted penetration of the corporate market:  pseudo-CA (=super-signer)  acceptation of the X.509 format (sep’98)  august 2002: rights given to PGP Co.

53

E-mail security

Gnu Privacy Guard (GPG)

 PGP is no more freeware (!) and it doesn’t exist

any more for Linux (!!) but only for Windows (!!!)

 GPG = PGP rewriting under GPL licence and

without any patented algorithm

 interoperable with PGP 2.x (with some problems)

and with OpenPGP (RFC-2440)

 DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5,

MD5, SHA-1, RIPEMD-160 e TIGER

 several graphical front-ends  for Linux, FreeBSD, OpenBSD, Windows

...

PGP – encrypted message

• ----BEGIN PGP MESSAGE-----

Version: 2.6.1 hIwDpHi4wHwVW/0BA/9oop5thKhbkVXxf1nILrk5X1sUD/L7WsfCBuQQqCLAufgW Cidy90kGO/zGKvrcPCK+CHQQqxxCbJDscFsmuQVArewaNIyxAvqVvNqOiVkhtc5Q NjL5VN/J9PosNcwKBah3u7vtamse1EMLtVVZxAr+rc7NJcvdG8XTbRQ1ihCpuaYA AADLVcTPRT1fpHVhO0zZn4kTpwjAty2sSpGh5hR8X8PTmWZvqjhS9joMHHTz5Esh SJQXn1HHZn8NdtHPJ4BGgVJ0FoTKpbe9zFrburR7gVBNiaAu2s1q05VXmeKgE7NW Lc74S0PHfSavpAbpHg+0dZDL6Pk9w0kVNlTbovWbjr6zuSb4Ga8Q27w9w3hF0bLX 0B0EpCy6vbOihr8OxVtO3KpRseshaCUs6LMd7kAaO5mjT+7JaqwH7U3GeKCAAa+z I0bpLA/muWBOEtEUh9g= =7T85

• ----END PGP MESSAGE-----

54

E-mail security

PGP – authenticated message

• ----BEGIN PGP SIGNED MESSAGE-----

Text of the message

• ----BEGIN PGP SIGNATURE-----

Version: 2.6.1 iQCVAwUBLuAyudzgsuo2HSCtAQESeAQAkUReUyhlAsRFktzjgIOtCogCFl6/elbM +20a71qpZWBoRviELK9sF7BQoQ3Moa35T18EeZtIHskj89mvDAAeuW3wzUcid5Hz ZiQ7vjKWqWb2lWgZ9oNbMyNMoDA+jMSCr8H0p9NguQPnNK4Lo+Gn251dBhsh4ISy vCzBoK7FLVM= =7RAd

• ----END PGP SIGNATURE-----

Security of multimedia electronic mail

MOSS (MIME Objects Security Services)

standard Internet  RFC-1847/1848

S/MIME (Secure MIME)

 standard de-facto RSA

MIME-PGP

RFC-2015 (PGP), RFC-3156 (OpenPGP)

X.421

 multimedia extension of X.400

55

E-mail security

MIME (Multipurpose Internet Mail Extensions)

MIME each part can be a multipart object – non-USA alphabets – “long” lines – binary data various data encodings recursive format – distinct parts – parts of different type multipart format text table Excel

• docum. Word

text table Excel

Secure multimedia electronic mail (MOSS o S-MIME)

 digital signature/encryption with X.509 certificates  protection of MIME messages

signed signed and encrypted encrypted

digital signature in S/MIME format encrypted envelope in S/MIME format

• docum. Word

encrypted envelope in S/MIME format digital signature in S/MIME format text table Excel

• docum. Word

56

E-mail security

RFC-1847

 MIME extensions for message security  for digital signature:

Content-Type: multipart/signed; protocol="TYPE/STYPE"; micalg="..."; boundary="..."

 with N body parts:  the first N-1 ones are those to be protected

(content-type: ...)

 the last one contains the digital signature

(content-type: TYPE/STYPE)

RFC-1847

 for the confidentiality:

Content-Type: multipart/encrypted; protocol="TYPE/STYPE"; boundary="..."

 with two body parts:  the key (Content-Type: TYPE/STYPE)  the encrypted message

(Content-Type: application/octet-stream)

57

E-mail security

“

S/MIME

 security of MIME messages  promoted by RSA  v2 published as a series of informational RFC:  RFC-2311 “S/MIME v2 message specification”  RFC-2312 “S/MIME v2 certificate handling”  RFC-2313 “PKCS-1: RSA encryption v.1-5”  RFC-2314 PKCS-10: certification request syntax

v.1-5”

 RFC-2315 “PKCS-7: cryptographic message

syntax v.1-5”

S/MIMEv3

 proposed standard IETF  RFC-2633

“S/MIME v3 message specification”

 RFC-2632

“S/MIME v3 certificate handling”

 RFC-2634

“Enhanced Security Services for S/MIME”

 RFC-2314 “PKCS-10: certification request syntax

v.1-5”

 RFC-2630

“CMS (Cryptographic Message Syntax)”

58

E-mail security

RFC-2634

 Enhanced Security Services for S/MIME  addresses the following subjects:  signature on the return receipt of a mail  security labels  secure mailing-list  signature of certificate attributes

S/MIME architecture

Architecturally based on:

 PKCS-7 (S/MIME v2)

CMS (S/MIME v3) specifies the cryptographic characteristics and the message types (equivalent to PEM)

 PKCS-10

format of certificate request

 X.509

format of public key certificates

59

E-mail security

S/MIME: algorithms

 message digest:  SHA-1 (preferred), MD5  digital signature:  DSS (mandatory)  digest + RSA  key exchange:  Diffie-Helmann (obbligatorio)  key encrypted with RSA  encryption of message:  3DES with 3 keys  RC2/40

MIME type

 application/pkcs7-mime, used for:  msg. encrypted (envelopedData)  msg. signed (signedData) addressed only to

S/MIME users because are encoded in base64

 msg. that contain only a public key (= certificate, in

signedData)

 standard extension: .p7m

60

E-mail security

MIME type

 multipart/signed  signed messages addressed also to users not

supporting S/MIME

 the message is in clear  the last MIME part is the signature  standard extension for the signature: .p7s  application/pkcs10  used to send a certification request to a CA

S/MIME: signature example

Content-Type: multipart/signed; protocol=“application/pkcs7-signature”; micalg=sha1; boundary=“-----aaaaa”

• ----aaaaa

Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello!

• ----aaaaa

Content-Type: application/pkcs7- signature Content-Transfer-Encoding: base64 MIIN2QasDDSdwe/625dBxgdhdsf76rHfrJe65a4f fvVSW2Q1eD+SfDs543Sdwe6+25dBxfdER0eDsrs5

• ----aaaaa-

61

E-mail security

Naming in S/MIME

 used for:  selecting the certificate  verifying the sender’s address  S/MIMEv2 uses the Email= or E= fields in the DN of

the X.509 certificate, but it is possible to use the extension subjectAltName with rfc822 encoding

 S/MIMEv3 mandates the use of the

subjectAltName extension with rfc822 encoding

Naming and MUA

 NS Messenger and MS Outlook Express check

that the sender is the same as the value of e-mail (in the DN) or with the first rfc822 field (in the subjectAltName)

 typical behaviour of S/MIMEv2  MS Outlook 2000 makes no verification among the

sender and the certified e-mail address

 typical behaviour of S/MIMEv3

62

E-mail security

Client-server e-mail services

Post Office MUA

 authentication of the user  authentication of the server  confidentiality/integrity of mail messages  on the server  while in transit

client - server e-mail services

 POP (Post-Office Protocol)  POP-2 (RFC-937), POP-3 (RFC-1939)

user authentication by means of a password in clear (!!!)

 APOP

user authentication by means of a challenge

 K-POP

mutual authentication by means of tickets

 IMAP (Internet Mail Access Protocol)  username and password in clear  can use OTP, Kerberos or GSS-API

63

E-mail security

POP-3 example

telnet pop.uqu.sa 1 10 +OKPOP3server ready<7831.84549@pop.uqu.sa> USERtest +OKpasswordrequiredfor lioy P A SSsample +OKlioymailboxlockedandready ST A T +OK2320 .......... QUIT +OKPOP3server signingoff

APOP

 APOP command replaces the set of commands

USER + PASS

 the challenge is the part of the hello line contained

among the parentheses < ... > (including the parentheses)

 syntax:

APOP user response-to-challenge

 response = MD5( challenge + password )  response encoded in hexadecimal  supported by Eudora

64

E-mail security

APOP example

telnet pop.uqu.sa 1 10 +OKPOP3server ready<7831.84549@pop.uqu.sa> A POPtest 36a0b36131b82474300846abd6a041ff +OKlioymailboxlockedandready ST A T +OK2320 .......... QUIT +OKPOP3server signingoff

POP: general considerations

 POP is acceptable only on a secure channel (e.g.

• n SSL)

 server APOP freeware by Qualcomm  use a POP / APOP password different from the one

for login because the post office must know it in clear

 the mail is transmitted however in clear  there is no server authentication

65

E-mail security

IMAP security



by default weak authentication LOGIN user password



strong authentication: AUTHENTICATE KERBEROS_V4 AUTHENTICATE GSSAPI AUTHENTICATE SKEY

 mutual authentication only if Kerberos is used  no protection of the transmission of messages  recent versions of Netscape and MS mailer can

use IMAP on SSL

RFC-2595 (TLS per POP / IMAP)

 RFC-2595

“Using TLS with IMAP, POP3 and ACAP”

 first the communication channel is opened then

the security characteristics are negotiated by means of a dedicated command:

 STARTTLS for IMAP and ACAP  STLS for POP3  client and server must allow to be configured to

reject user and password

 client compares the identity in the certificate with

the identity of the server

66

E-mail security

Separate ports for SSL/TLS?

 discouraged by IETF due to the following reasons:  involve different URLs (e.g. http and https)  involve an incorrect secure / insecure model (e.g. is

40-bit SSL secure SSL? is insecure an application without SSL but with SASL?)

 not easy to implement “use SSL if available”  doubles the number of necessary ports  … but present some advantages:  simple to filter traffic on packet-filter firewalls  SSL with client-authentication allows not to expose

the applications to attacks

67