Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Information Systems Security > Security of network applications > Flashcards

Security of network applications Flashcards

1
Q

Approaches to security of network applications

A

We have a very poor standard, very weak authn (interceptable pwd) or ip-address based authentication (can be spoofed). And even if stronger systems are used (OTP, challenge response), that prevent problems with authn, there are issues related to data snooping/forging, shadow servers/MITM, replay and filtering.

Approaches to avoid problems:

  • Channel security: nodes negotiate encryption algo/keys before communication starts
  • Message/data security: each data item is protected (individually) by being wrapped inside a secure container (e.g. PK-SSL).
  • Mixed approeach is also possible: secure data inside a secure channel, the secure channel, however, is the preferred choice for applications such as the web.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Apprach to security of net. applications: message/data security

A
  • Message/data security: each data item is protected (individually) by being wrapped inside a secure container (e.g. PK-SSL).
    • sender is creating the protection
    • data that doesn’t need security is not protected
    • only single authn is achieved
    • integrity and privacy are self-contained in the message.
    • protection remains even if data exits network (and is stored at dest): allows non-repudiation, but requires some modifications to the application.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Approach to security of net. applications: Channel security

A
  • Channel security: nodes negotiate encryption algo/keys before communication starts
    • all traffic will be protected by secure channel after set-up.
    • can get single or mutual authn, integrity and privacy (since features are negotiated at the start)
    • no possibility of non-repudiation when data exits the secure channel
    • widely adopted because easy to implement (can be done at OS level), doesn’t require modifications of applications
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Internal and External Secuirty to Applications

A
  • Internal:
    • each app. implements security internally
    • possible implementation errors (inventing sec. protocols is hard)
    • doesn’t guarantee interoperability between app.s
    • communication channel is the part in common.
  • External:
    • session would be ideal to implement sec. but TCP/IP doesn’t have one.
    • secure session level was proposed: “secure logical channel”
      • defacto standard
      • uses socket to send data enriched with protection
      • simplifies application dev. work
      • avoids implementation errors
      • app. is free to use it or implement its own sec.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Secure channel products

A
  • SSL/TLS: most widely used, intially SSL -> TLS
  • SSH: was successful (when export of crypto products from USA was limited), nowdays is niche.
  • PCT: MSFT alternative to SSL. Fiasco.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

SSL

A

Initially SSL (Secure Socket Layer) was proposed by Netspace Communications, that needed a secure protocol to implement e-commerce on the web. SSL is a secure transport channel (session level) with some properties:

  • Peer authn and optionally mutual authn
    • compulsory to have server authentication when SSL channel is opened (since it was made for e-commerce).
    • possible to do also client authn.
    • session level protocol means that username/pwd aren’t required.
  • message confidentiality: optional because maybe authn is enough
  • message authn and integrity: compulsory, are used to prove who created the message and that the message has not been modified during transmission.
  • replay attack and filtering attack protection
    • replay attacks will be detected as weel as filtering attacks (part of the data being deleted)

Success of SSL is based on the fact that is built on top of TCP, making it available to all protocols that use it: HTTP, SMTP, NNTP, FTP, TELNET.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

SSL: Authn and integrity

A
  • peer authentication at channel setup:
    • server authenticates itself by sending its public key cert. (x.509) and by responding to an implicit asymmetric challenge
    • client authn is optional, is done with public key certificate and explicit challenge to prove the possesion of the private key by the client)
    • if authn fails the channel is not opened.
  • authentication and integrity of data achieved using:
    • a keyed-digest (SHA-1 or better) to demonstrate authentication and integrity.
    • A message IDentifier (number to avoid reply and cancellations)
    • TCP doesn’t deliver to upper levels out-of-order or duplicate packets. So if a packet has a duplicate ID or skipped a number we are under attack.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

SSL: confidentiality

A
  • Optional.
  • Client generates a session key, that later is used for symmetric encryption of data (RC4, 3DES, IDEA, AES)
  • Key exchange with the server occurs via public key cryptography (RSA, Diffie-Hellman or Fortezza-KEA)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

TLS connection opening

A

TLS is a negotiation protocols.

In the security config. parties agree on algorithms/keys.

Next, if they have agreed about a set of algorithms, the server would give back its certificate which must contain the name corresponding to the connected URL. Then, the server must use its private key to implicitly respond a challenge (on the picture there is a simplification, the browser is not sending a challenge).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

SSL3 architecture

A

Base: network protocol (IP), reliable transport protocol (TCP), on top of the latter there’s a record protocol to transmit SSL records (i.e. protected data).

Inside the record protocol there’s application data, altough it it initially used for the handshake protocol.

The change cipher spec protocol is used at the end of the handshake to tell systems that the agreement ended.

Alarm protocol is to signal missing or duplicated packets, or the end of the communication.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

SSL session-id

A
  • The identifier is sent by the server, it is used to avoid re-negotiation of crypto parameters of each SSL connection => more connections can be part of the same logical session.
  • If the client sends a valid session-id when opening a SSL connection, negotiation is skipped, and data is exchanged securely from then on.
  • the server can reject use of session-id (always or according the the validity set by its policy)

Since a typical use of SSL is to request a lot of items from the same server, it becomes computationally expensive to negotiate parameters with the same server at each request.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

SSL-3 / TLS record protocol

A

If large files need to be sent using SSL, packets are fragmented and compressed (only in old versions, it was vulnerable to attacks).

SSL has a maximum packet length of 32KB.

Then a MAC is computed to protected authentication and integrity.

If confidentiality is wanted too, padding is added (to match multiple of block-size).

The packet is then encrypted and the header prepended to make it recognizable as an SSL segment inside TCP.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

TLS-1.0 record format

A
  • uint8 type = change_cipher_spec (20), alert (21), handshake (22), application_data (23)
  • uint16 version = major (uint8) + minor (uint8)
  • uint16 length:
    • ≤ 214 (record not compressed) for compatibility with SSL-2
    • ≤ 214 + 1024 (compressed records)
    • This means that it is a 5-byte header
  • Plus a payload of max 16kB
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

SSL computation of MAC

A
  • MAC = digest_fun(key, seq_number || type || version || length || fragment)
  • In order to protect authentication and integrity a MAC is computed with a specific hash function, using the key used during handshake.
  • everything is protected.
  • Notes:
    • changes based on the direction of the message (otherwise we could replay packets sent from client to server as part of server to client.
    • seq-number is a 64bits integer that is never transmitted, it’s implcitly calculated. The seq-number allows for a lot of segments, the channel must be closed after exhausted.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

SSL/TLS handshake protocol

A
  • Needed to:
    • agree on set of algos: integrity and confidentiality
    • exchange random numbers between client and server (used for subsequent generation of keys)
    • establish a symmetric key by means of public key operations ( RSA, DH, Fortezza)
    • Negotiate the session-id: when contacting server multiple times
    • exchange necessary certificates
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

TLS sessions vs connections

A
  • Session:
    • logical association between client and server
    • created by the Handshake protocol
    • defines a set of cyptographic parameters
    • is shared by one or more SSL connections
  • Connection
    • transient tls channel betwen client and server
    • assosicated with one specific TLS session
17
Q

SSL relationship among keys and sessions

A

The relationship among keys and session between the same client and a server:

  • During the handshake two public keys are established:
    • pre-master secret (long-term server secret)
    • master secret
  • When the connection is the first in the session, the pre-master secret is generated.
  • After that, the client and the server generate a random number each, combined with the pre-master secret to create the master secret (symmetric operation, e.g. key derivation function)
  • Each connection keys for MAC, encryption and the IV are generated by derived by combining the master secret with random values (different for each connection)
  • Only persistent thing in the sessione = master secret, generated by the pre-master secret and the random values generated everytime there is a new connection.
18
Q

Perfect forward secrecy.

A
  • If a certificate is valid for signing and encrypting messages, then it can be used for both authentication and key exchange (asymmetric encryption of session key).
    • If an attacker sniffs traffic for a long time and discovers the private key, they will be able to decrypt all traffic: past, present and future.
  • Perfect forward secrecy is achieved when an attacker that discovers the private key can only decrypt present and future traffic.
    • To achieve it, we need to use a one-time key for encryption.
    • This also imples that the keys used for authentication should be different than the ones used for encryption.
19
Q

Ephemeral mechanisms to achieve Perfect Forward Secrecy

A
  • Encryption key is a one-time key generated on the fly
    • Key must be signed to prove authenticity
    • DH is suitable, RSA is not because key generation is too slow (prime numbers…)
      • compromise to use RSA = generate 1 key to re-use 10-100 times
    • We obtain PFS because the server’s private key is only used for signing the key:
      • if (temporary or short-lived) private key is compromised, the attacker can only decrypt traffic generated with it.
      • compromise of the long term key is an issue for authentication, but not for confidentiality.
  • Modern TLS servers use ECDHE(EC Diffie-Hellman Ephemeral) with on-the-fly generation of DH parameters.
20
Q

Problem with TLS and virtual servers

A
  • Virtual servers: multiple servers that share the same ip (es. home.myweb.it=1.2.3.4 , food.myweb.it=1.2.3.4) since we are short of ipv4 addresses.
    • HTTP/1.1 handles it easily using the Host header.
    • Using HTTPS it is diffult, because TLS is activated before HTTP, how can we know which certificate to provide?
  • Solutions:
    • Collective (wildcard) certificate
      • e.g. CN=*myweb.it
      • private key shared by all servers
      • there are some behavioral non uniformities between browsers
    • certificate with a list of servers in subjectAltName (subject alternative name)
      • p. key shared by all servers
      • need to re-issue certificate at any modification of the list
    • use the SNI (Server Name Indication) extension
      • in ClientHello (RFC-4366)
      • best solution, but limited support by browsers and servers
21
Q

ALPN extension

A

TLS protects application segments. The application protocol may have various versions, which one should be used?

Application-Layer Protocol Negotation (for TLS-then-proto)

  • to speed up connection creation by avoiding additional rountrips due to application level negotiation
    • ClientHello asserts ALPN=true + list of supported app protocols
    • ServerHello asserts ALPN=true + selected app. protocol
  • particularly important to negotiate HTTP/2 and QUIC (UDP-based HTTP), since Chrome and Firefox support HTTP/2 only over TLS.
  • also useful for servers that use many application protocols
  • possible values are http/1.{0,1}, h2, h2c
22
Q

DTLS

A
  • TLS had success, why not use the same idea for datagrams (UPD packets)? (TLS can be used only on reliable protocols)
  • DTLS is Datagram Transport Layer Security, it applies the same concepts of TLS but for datagrams.
    • It doesn’t offer the same features (e.g. protection from replay attacks is impossible)

DTLS competes with IPsec and application security, there are a few option to take into consideration when designing an architecture. For example SIP (VoIP protcol) we could use:

  • IPsec (SIP packets over IP)
  • TLS (for SIP over TCP)
  • DTLS (only for SIP over UDP)
  • with secure SIP (app level sec)

How to decide: what’s easier to implement?

23
Q

TLS downgrade problem

A
  • There are many versions of TSL, SSL 1,2,3, TLS 1.0, 1.1, 1.2.
    • Old versions are less secure than modern ones.
  • Normal behavior is for the client to send ClientHello message, containing the highest supported version, the server then will reply with the version to be used (ServerHello), which is the highest in common.
  • Problem: some servers, instead of doing what described above, just close the connection.
    • The client has no choice but to try again with a lower protocol.
    • Downgrade attack: attackers sends fake server response to force repeated downgrade until reaching a vulnerable version, in order to execute a suitable attack (e.g. Poodle)
24
Q

TLS fallback signalling Cipher Suite Value (SCSV)

A

Extension reported in RFC-7507 to prevent protocol downgrade attacks.

  • Achieved using a new (dummy) ciphersuite which is not listing any algorithms, just mentioning TLS_FALLBACK_SCSV that should be sent by the client when opening a downgraded connection (by putting it in the ciphersuite list)
  • Example: client proposes 1.1 -> downgrade to 1.0. The response will be se sent with 1.0, but it’s possible to do better, so the ciphersuite list includes FALLBACK_SCSV.
  • If it is possible to use a better version, but it isn’t being used, the server sends the value “inappropriate_fallback”.
    • if there was an error, the channel is closed, and the cliend should retry with its highest protocol version.

Many servers don’t support SCSV, but most have fixed their bad behavior, now browsers can disable insecure downgrade (since 2015/2016).

25
Q

HTTP security

A
  • HTTP/1.0 defines 2 security mechanisms:
    • address-based: access control based on IP of client (ipspoofing => useless)
    • password-based: access control based on username and password (in clear (Base64) => sniffable)
  • HTTP/1.1 introduced digest-authentication based on symmetric challenge response protocol (RFC-2617)

HTTP realm: suggestion that will be displayed in a pop-up message to suggest to the client which username and password should be used.

26
Q

HTTP digest authentication

A

Implicit challenge, response must use a password.

Keyed-digest computation:

  • The browser: HA1 = md5(A1) = md5(user “:” realm “:” pwd)
  • The browser: HA2 = md5(A2) = md5(method “:” URL)
  • The browser sends to server: Response = md5(HA1 “:” nonce “:” HA2)
    • Server uses a nonce to avoid replay attacks
    • The authentication server may insert a field “opaque” to transport state information (e.g. a SAML token) towards the content server.

In the picture the server asks for digest authentication after refusing to the request.

27
Q

HTTP and SSL/TLS approaches

A
  • TLS then HTTP (RFC HTTP over TLS)
  • HTTP then TLS (RFC TLS within HTTP/1.1)
  • SSL then HTTP is widespread but undocumented.

Both approches give equivalent security, but they are not equivalent in the way they impact applications, firewalls and IDSs architectures:

  • Applications:
    • TLS then HTTP
      • Changes nothing for the application developers.
      • TLS is always on, even for pages that don’t need it.
    • HTTP then TLS
      • Developer has the option to decide where/when to activate TLS.
        • Must be cautios and aware of TLS.
  • Firewalls:
    • TLS then HTTP
      • there are 2 ports 80 and 443/HTTP over TLS, firewall can easily distinguish the traffic: 80 -> clear, 443 -> encrypted.
    • HTTP then TLS:
      • traffic can’t be checked, it’s all unprodected traffic, that will be left like this or encrypted later, on rules decided by developer.
      • Firewall is not anymore in charge of selecting only secure channels.
  • IDSs:
    • TLS then HTTP
      • IDS is not able to inspect HTTPS traffic since it is encrypted.
      • can look at the initial part and see when the channel is turned to a secure one.
    • HTTP then TLS: can inspect everything.
28
Q

Web Application Authentication

A

The earlier the authn the smaller the attack surface:

  • TLS authentication: only TLS library bugs can be exploited for attacks.
  • HTTP authn: the above + HTTP web server bugs (big piece of SW -> potentially more bugs)
  • Application authentication: above + application bugs

Automatic application authn

It is possible to identify the user that opened a channel (without asking for user/pass). Possible through a semi-automatic mapping between credentails extracted from X.509 certificate and the users of HTTP service and/or OS, so that when authentication is performed at transport level, it is also recognized at application level.

29
Q

Should form requesting user/password be in HTTPS?

A

Not really, it’s only important that the action of the form is towards a rule that is TLS-protected (

).

Altough if the page is not protected, users might trust fake pages that are not SSL protected (phishing), not many people have knowledge of examining the form action field.

30
Q

HTTP Strinct Transport Secuirty

A

New HTTP header: HSTS. Used by the HTTP server to declare that all its interaction with the user-agent must only be via HTTPs.

Features:

  • prevents protocol downgrade and cookie hijacking
  • it is valid only in HTTPs response
  • may include subdomains(recommended0
  • May be pre-loaded (browsers may have already knowledge that when a certain domain is contacted TLS must be used):
    • dangerous because if HTTPS fails there is no possibility to contact server
    • Preloaded list maintained by Google and used by many web browsers.
31
Q

HTTP Public Key Pinning

A
  • HPKP: To avoid the creation of fake certs for a website by malicious actors, the manager of the website can insert in the header the hash of the public key that is using and the UA (browser) caches the key and will refuse to connect to a site with a different key, even when presented with a valid certificate.
  • This is a TOFU (Trust on First Use) technique that can be dangerous when losing control of the key or when it must be updated
    • always include a backup/secondary key
  • Modes:
    • Enforcing: connection is closed if key is different.
    • Report-only: if different key -> the connection proceeds, but it is reported to the user and the server.
32
Q

Application security of e-payment systems

A
  • why?
    • failure of digital cash, technically and politically (e.g. DigiCash)
    • Failure of a dedicated payment protocol (SET, Secure Electronic Transactions): technical and organizational issues.
    • Most widely used approach is transmitting credit card number over TLS channel
      • no guarantee against fraud, since most credit card numbers are stolen offline. On the internet it’s very easy to spend money from stole credit cards, on the other hand.
        *
33
Q

Web-based payment architecture

A
  • The merchant should not be asking about the payment data (too risky)
    • Should use payment gateway
      • PG creates a secure channel where credit card data is sent.
      • PG creates a virtual POS that uses to create a transaction valid for the payment network, that checks if the data is valid.
      • Upon receiving a positive response from the payment network, the PG replies to the merchant that everything went fine.]
  • The buyer owns a credit cast adn a TLS-enable browser.
  • Effective security depends on the security level of both the server and the client.
  • The merchant doens’t know anything about the payment information, which is good, drawback: PG could profile the merchant (know data about its sales).
  • If merchant wants to rely on its own architecture to perform the payment, it should comply with PCI DSS.
34
Q

PCI DSS

A

Payment Card Industry Data Security Standard, and it is required by all credit card issuers for Internet-based transactions. It is very detailed set of technical prescriptions compared to other security standards (e.g. HIPAA = Health Insurance Portability and Accountability Act). Complex, so company prefer to rely on PG.

design, build and operate a protected network:

  • R1 = install and maintain a configuration with firewall to protect

access to the cardholders’ data

  • R2 = don’t use pre-defined system passwords or other security parameters set by the manufacturer
  • protect the cardholders’ data:
  • R3 = protect the stored cardholders’ data
  • R4 = encrypt the cardholders’ data when transmitted across an open public network

establish and follow a program for vulnerability management

  • R5 = use an antivirus and regularly update it
  • R6 = develop and maintain protected applications and systems
  • implement strong access control
  • R7 = limit the access to the cardholders’ data only to those

needed for a specific task

  • R8 = assign a single unique ID to each user
  • R9 = limit physical access to the cardholders’ data

regularly monitor and test the networks

  • R10 = monitor and track all accesses to network resources and cardholders’ data
  • R11 = periodically test the protection systems and procedures

adopt a Security Policy

  • R12 = adopt a Security Policy

Information Systems Security (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions