Network Application Security Flashcards
What are the data transformation steps when sent via a TLS channel with the TLS_DHE_DSS_WITH_AES_128_CBC_SHA ciphersuite with ZIP
1) fragmentation
2) PACK.DATA = zip compression (PACK.DATA)
3) mac in this case a keyed digest using sha256 then I guess PACK.MAC = HMAC- SHA256 (key_auth_client_to_server, packet) (considering padding if tls or without considering it if ssl <= 2.0)
4) padding
5) generation IV, so PACK.IV = rand (128)
6) encryption using aes, then PACK.DATA = AES-128-CBC (PACK.IV, key_comp_client_to_server, PACK.DATA)
7) send packet, i.e. send (PACK) # which will contain IV, DATA and MAC
TLS security properties with algorithms and keys.
Starting with TLS-1.2 we have:
- PEER AUTHN: mandatory server, optional client. C / R ASYM implicit and
explicit.
- DATA CONFIDENTIALITY: optional, SYM
- DATA AUTHN / INTEGRITY: mandatory, keyed-digest negotiated
- FILTERING: mandatory, implicit MID
- REPLAY: mandatory, implicit MID
The algorithms used are HMAC for integrity, and DH + DSA + 3DES for confidentiality
Describe how TLS client authentication works. Discuss its advantages and disadvantages.
1) certificate request (client): optional, requested by the server during the handshake phase
2) certificate (client): Carries the certificate for client authentication. The certificate must have been issued by one of the given CAs listed by the server in the Certicate Request message.
3) Cetificato verify: This is an explicit signature proof. It actually verifies that you have the private key and intend to use it in that context. The hash is calculated on all
handshake messages preceding this one and is signed with the client’s private key (to
avoid impostors)
TLS client authentication vs HTMLform-based authentication: advantages, disadvantages and solutions
TLS client auth: In case the SSL channel has been activated with client authentication, to authenticate the user must provide an X.509 certificate, in addition to having to respond correctly to the challenge. In this case, the server can perform a mapping to let the application developer know the credentials of the user who requested access to a particular resource.
The advantage is that the attacker will only be able to exploit the bugs contained within TLS; consequently you will have a very small attack surface.
The disadvantage is that unfortunately this is very often not possible because users rarely have an X.509 certificate, or even if they do, it is not certain that the systems engineer has activated the credentiality mapping function.
HTML form-based: the client sends its data after entering it in an html form
The disadvantage is that it simply sends the credentials encoded in base64 and are not protected by encryption so you can sniff the credentials and the server must also be careful to save them unencrypted while the advantage is that it is quick and easy to implement.
A company wants to do TLS client auth on a web server: advantages and disadvantages and precautions to be applied on client and server.
Advantages: strong authentication, reduced attack surface, no password stored on the server, etc …
The disadvantage is that unfortunately this is very often not possible because users rarely have an X.509 certificate, or even if they do, it is not certain that the systems engineer has activated the credentiality mapping function.
Tips: HSM on the server to put private K, smart card or secure device for private K on the client, HSTS and HPKP (which have nothing to do with the auth client but apparently they had to be said).
Considering the TLS-1.0 protocol, explain what security properties it offers and for each of them indicate whether it is mandatory or optional and how it is achieved.
server authentication (mandatory): when the channel is opened, the server:
1. authenticates itself by sending its public key, typically contained within an X.509 certificate;
2. undergoes a sort of asymmetric challenge to prove that it knows the private key corresponding to the public key in the certificate;
* client authentication (optional): when the channel is opened, the client authenticates itself in the same way as the server;
* authentication and integrity of messages (mandatory): all transmitted data are protected by MAC keyed-digest (eg SHA-2) (the digital signature would be too slow for data flows);
* confidentiality of messages (optional): all transmitted data is encrypted with a symmetrical session key (eg 3DES):
- the client decides the key;
- the client communicates the key to the server through public key cryptography (eg RSA, DH);
* protection from replay attacks and filtering: each message is numbered with a MID3, ensuring complete protection possible thanks to the reliable transport protocol (not partial as in IPsec4):
- replay: messages must always arrive in the same order in which they were sent and must not be duplicated;
- filtering (= deletion): messages must not be missing.
* message protection: according to various studies, 10% of messages really need confidentiality (optional), while 100% need authentication and integrity (mandatory).
List and explain the features of SSL.
SSL (Secure Socket Layer), originally proposed by Netscape, is a protocol for creating secure transport channels. SSL lies roughly at the session layer, between the transport layer and the application layer.
Features:
* server authentication (mandatory): when the channel is opened, the server:
1. authenticates itself by sending its public key, typically contained within an X.509 certificate;
2. undergoes a sort of asymmetric challenge to prove that it knows the private key corresponding to the public key in the certificate;
* client authentication (optional): when the channel is opened, the client authenticates itself in the same way as the server;
* authentication and integrity of messages (mandatory): all transmitted data are protected by MAC keyed-digest (eg SHA-2) (the digital signature would be too slow for data flows);
* confidentiality of messages (optional): all transmitted data is encrypted with a symmetrical session key (eg 3DES):
- the client decides the key;
- the client communicates the key to the server through public key cryptography (eg RSA, DH);
* protection from replay attacks and filtering: each message is numbered with a MID3, ensuring complete protection possible thanks to the reliable transport protocol (not partial as in IPsec4):
- replay: messages must always arrive in the same order in which they were sent and must not be duplicated;
- filtering (= deletion): messages must not be missing.
TLS-then-proto and proto-then-TLS approaches: explain the functioning, advantages and disadvantages of the two approaches.
TLS then proto: that is, first a secure channel is opened and then the protocol for data transport is used. Security is not managed by the Web server programmer, but is managed by the system engineer: it is the latter’s job to activate TLS before making the Web application accessible. This has the advantage of requiring less work from developers, but at the same time they will have no control over the security systems; it will be necessary to trust the work of the systems engineers. It is therefore
necessary to have a synchronization between the work of programmers and that of systems engineers.
proto then TLS: In this case you have the initial opening of a normal channel via protocol, and the server will decide if you want to do security or not. It is therefore possible to upgrade a normal channel to TLS. it is the developer who must take care of security: when a user requests access to protected resources, it is necessary to stop the normal dialogue through the protocol, transform the channel into safe and only at that point can the dialogue resume. This results in a higher workload for the developer as he will have to take care of security as well, but this can also be seen as an advantage as it is the developer himself who controls if and what security you want to have.
As far as firewalls are concerned, the two solutions are not equivalent mainly for the reason that they use different ports.
As for the IDS, if you use TLS then proto the IDS will only be able to see a request to open a secure channel. Once the channel is open it will no longer be possible to see anything.
With proto then TLS, on the other hand, the IDS can see that the channel has been created and that for a specific request the server has decided to transform the channel into secure. The IDS will still not be able to see anything as long as TLS is active, but at least you have control over which URLs security is activated.
You want to control access to web pages hosted by a server by operating only on the configuration of the server itself. Identify the possible techniques that can be used, indicating their advantages and disadvantages.
(Professor’s answer)
- INGRESS: simple, level S1. cons: IP spoofing, no per-page
- IP-SEC: level S2. disadvantages: also configure the client, no per-page
- TLS c / authn: level S3, per-page. disadvantages: certified clients that not everyone has.
- HTTP basic / digest: simple, per-page. disadvantages: S4 level, if basic -> TLS (to avoid sniffing)
- FORM based authn: integrity in the application. disadvantages: level S5, the actual strength depends on the technique used.
Which is the standard situation security wise in a network?
- week authentication based on IP addresses or ID and paw: this leads to possible IP spoofing attack and password snooping attack
- replay and filtering attacks
- data snooping and data forging attack
- creation of shadow server and MITM attack
Channel security and message security
- Channel: data transmitted in a secure channel have, as security properties, single or mutual authN, integrity, confidentiality but just when they pass through the Janelle. There is no possibility to have the non-repudiation property. It doesn’t require app modification. All the data that pass through the channel are protected
- Message: those security properties are self-contained in the message and do not belong to the channel. The authentication can just be single and not mutual, and it may be non-repudiation. This solution requires app modification. Only selected data are protected
Security internal and external to applications
- internal: each app implements security internally and the common part between two apps is limited to the communication channels (socket) because they use the same TCP-IP network. There is the possibility of implementation errors because inventing security protocols is not simple and this solution does not guarantee interoperability
- external: the session level would be the ideal one to be used to implement many security functions BUT it does not exist in TCP/IP. That is why a secure session level was proposed: this level simplifies the work of application developers by avoiding implementation errors. App can have internal security too.
Which are the secure channel protocols?
- SSL/TLS: most used
- SSH: nowadays is a niche product
- PCT: one of the fiascos of MS
TLS: main features
- Transport Layer Security Protocol
- it gives the possibility to create a secure transport channel AT SESSION LEVEL
- security properties: peer authN (server or server+client), message confidentiality + authN + integrity, protection Fromm replay and filtering attacks
- easily applicable to all protocols based on TCP such as HTTP, SMTP, TELNET, …
- SSL-2 -> SSL-3 -> TLS1.0 -> TLS1.1 -> TLS1.2 -> TLS1.3
- everything below TLS 1.2 is insecure and deprecated
- example of official ports for SSL/TLS application: 443/tcp is https, 465/tcp is smtps…
TLS: peer authentication
- the server authenticates itself by sending its public key through a X.509 certificate and by responding to an implicit asymmetric challenge to show that it knows the secret key
- the client authN is optional and optionally it is made thanks to a X.509 certificate and an explicit challenge
TLS: data authentication, integrity and confidentiality
- keyed-digest +
- implicit MID to avoid replay and filtering attacks
- The client generates a session key used for symmetric encryption of data. To exchange the generated key with the server it uses public-key cryptography (ex. RSA or DH).
- Since TLS1.2 authenticated-encryption is also available
