Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
10 Cards in this Set
- Front
- Back
|
* After receiving a message through the use of public key encryption and private key decryption. How do you know the public really belongs to the sender? What if an imposted replaced the public key? One way used by OpenSSH is to use RandomArt |
Certifying authorities (CA) : * CA is a private company that issues digital certificates (for a fee). To issues a certificate the CA must verify the identity of the subject requesting the certificate. * By doing this the CA guarantees: - the identity of the subject - customers will feel confident when they see that an online business is properly identified - customer is trusting the CA. Without this trust PKI does not work. * After validating the subject the CA issues a cert. To do this it takes information about the subject and passes it through a hashing algorithm. It then takes the resulting hash value and encrypts it with the CA's private key. The cert has not been signed. CA hierarchies: - CA usually exist in a hierarchy - The certificate of each CA is signed by its parent. The root CA has a self-signed cert - the browser comes with copies of trusted CAs installed Digital certificates: - a document that contains a public key, and other relevant information such as owner's name, contact details etc. - Main types of certificate used on the internet: * server certificates, personal certificates, software publisher certificates Main fields of the ITU-X-509v3 certificate are: - cert serial number - cert validity start and end dates - signature algorithm (eg: RSA) - subject's unique name - subject's public key - issuer's name - issuer's signature Certificate chains: - When client is presented with a certificate from a server, its usually comes with chains. The cert chain is every cert from the branch in the CA hierarchy to the root CA For eg: when a client receives a cert from a website like wswt.net (signed by Melbourne CA) it also gets the cert from the Melbourne CA, Australian CA, then the root CA. If the client has a copy of the root CA's cert, then it will accept the cert from wswt.net, or else it wont. Certificate revocation: * when the issuer's private key has been compromised, any cert issues by them can also be compromised. In that case, cert can be removed from the client in the same way it was added. |
|
|
Verifying the certificate: - Check the cert validity period (has it expired?) - obtain the public of the CA's certificate - use the public key to decrypt the signature - this value is the hash value generated by the issuer - Run the contents of the certificate through the hash function - compare the hash values, if they are the same, the cert is authentic (has not been modified) |
SSL next |
|
|
Secure socket layer (SSL): - Secure web servers employ encryption for data privacy - Most sites use an implementation of OpenSSL (a free implementation of SSL) - SSL operates in the OSI session layer. In the TCP/IP, it creates a new "intermediate security layer" between the transport and the application. |
- SSL provides many features useful for a secure connection: * bi-directional authentication between the clients and servers *selection of cryptographic algorithms to use * handshaking to establish a secure connection - OpenSSL good tool for programming and developing encrypted systems HTTPS and port 443: - secure web servers generally do not run on port 80 ( as used for HTTP) - The standard for HTTPS (secure HTTP) is port 443 - other port used along with 443 for admin and other security related issues - |
|
|
The SSL Handshake: - When a web client connects to a secure web client, the SSL handshake establishes how encrypted data will be exchanged. - The handshake involves these steps: * The client connects to the secure web server * The secure web server sends it cert to the client * optionally the client sends its cert to the web server * the client sends which cipher suites it supports * the web server selects a cipher suite * the client validates the server's cert * optionally the server validates the client's cert *The client generates a session (symmetric) key based on the cipher suite chosen by the server *The client encrypts the session key with the web server's public key * The client sends the session key to the web server * Now all communication, for this session only is encrypted with the session keys. |
next |
|
|
Access control and authentication: - Not all documents on a web server are available to all users - Web site admins use number of methods to limit access: * disallowing access from certain IP addresses or domain names * allowing access from only certain IP addresses or domain names * Authentication by requiring a username/password * encrypting documents * access control which includes authentication is an integral task for any web server Common errors which compromise web security: * getting the file permissions wrong * allowing symbolic links to be followed without auditing. Symbolic links may be outside of the web document tree *Allowing unchecked executable scripts. Can be tricked into displaying password files |
HTTP Authentication: 2 types of challenge response patterns: - Basic authentication - an implementation of authentication specified in RFC 2617. Most widely used means of authentication on the net. Password is transmitted by client to sever (risk) - Digest authentication - a variation that use shared knowledge between client and server to avoid transmitting the password |
|
|
Basic authentication behind the scenes: * The client sends request to a page that is protected with basic authentication GET/local/www/secret/index.htm HTTP/1.1 * The server replies that is client is unauthorised * The browser asks the user for a username and password * Server responds given that the credentials match |
Drawbacks of basic authentication: * not secure. It should only be used to limit access to documents or scripts which security and authentication don't really matter too much - when the client's username and password is transmitted to the server, it is encoded with a public algorithm. NOT ENCRYPTED. - The client remembers the username and password and transmits it on every request for a page in the protected path - This gives an attacker ample opportunity to intercept the request and use it in a 'replay' attack - Since the authorisation string never changes the attacker can put that in the header and pretend to be a validated user - Once captured U/N and password can be easily decoded without even knowing plaintext. Since HTTP is stateless you can copy the Base-64 encoded string and use it for your own requests. |
|
|
Digest authentication: - HTTP 1.1 supports this improved authentication method. - The server sends a random number to the client called nonce and demands authentication - The client calculates a hash value (using MD5 by default) for the nonce u/n and password, HTTP methods, and the requested URL combines all together. - The hash value is sent to the server, which can compare it with one it calculates itself. If they math the u/n and password are correct |
Digest authentication behind the scenes: - in response to the client's request, the server issues that digest authentication is required. - After obtaining the u/n and password the user (person), the client (browser) sends a new request/response Advantages of digest authentication: - The actual is never transmitted - The requested URL is included in the hash. An attacker can't cut and paste the hash value of a different URL. The nonce can be timestamped, and can be set to expire within a time limit, eliminating the opportunity to cut and paste attacks for scripts. - its an upgrade for the basic authentication for small-scale, low-security websites. it is still not secure. The contents of web page is still in plaintext across the internet. |
|
|
Cookies: - mechanism for identifying and maintaining information about clients (users) connecting to the web - stored client side on the browser - information stored in cookies is shared between the web server and the web client with HTTP headers. Setting cookies: - The first a browser connects to a site: * The web server's response includes the set-cookie header * The site puts info it wants to store about the client into the header * when the response arrives at the browser, the info in the cookie header is stored on the client's disk The next time a browser connects to the same website: * The browser checks its list of cookies * as it has a cookie for this site, it includes the cookie info in the cookie header of its request |
Using cookies: - cookies allow web servers to store small amount of information about the client. More efficient if the this info is stored client side - can be used to personalise a website - can be used to store website authentication details - instead of storing your u/n and password this is achieved with a session variable. - cookies also lets web application maintain states two types of cookies: - Persistent cookie - live as long as they don't timeout or are deleted - Non-persistent cookie - also known as session cookies - only exist while the browser remains active |
|
|
Session cookies: - used in web applications such as shopping carts to store info between pages. Done via a session variable. This is a unique set of characters that correspond with the user's details kept on the web server. - using cookies authentication details is a matter of extending the life of the cookie beyond the session. But for security reasons, most application that use session cookies for authentication include a timeout flag, after which the user must re-authenticate. |
Third party cookies - It is possible and common, for web sites to use third party cookies - This done by including a web resource such as an image from the web server than the one containing the HTML file - two ways of doing this: using banner ads, using 1x1 pixel knows as a web bug - either way when you browse the site, you get the site's cookies also the third party cookie - if a banner ad gets enough cookies from users it can create a picture of the user's browsing patterns and purchasing behaviours - most browsers allow you to disable third party cookies |
|
|
done |
