https strict transport security

Open Web Application Security Project

My Session

Server

Open Web Application Security Project

Web ServerHTTP

HTTPSSSL/TLS

Validation

Symmetric / Asymmetric Encryption

HSTS

Web Server

ServerWebMail

FTP

DNS

21

53

25

21

53

25

RHEL 7

80

443

80

443

Web Server

A server is a running instance of an application (software) capable of accepting requests from the client and giving responses accordingly.

Service

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=http

ServerWebMail

FTP

DNS

21

53

25

21

53

25

RHEL 7

80

443

80

443

HTTPHTTP

HTTPHTTP

HTTP

HTTPHTTP

HTTPHTTP

HTTP

HTTP

HTTP

HTTPHTTP

HTTP

HTTPSHTTPS

HTTPS HTTPS

HTTPS HTTPS

HTTPS

HTTPS HTTPS

HTTPSHTTPS

HTTPS

HTTPSHTTPS

HTTPS

HTTPS

Web Server

X

ServerWebMail

FTP

DNS

21

53

25

21

53

25

RHEL 7

80

443

80

443

HTTPHTTP

HTTPHTTP

HTTP

HTTPHTTP

HTTPHTTP

HTTP

HTTP

HTTP

HTTPHTTP

HTTP

HTTPHTTP

HTTP HTTP

HTTP HTTP

HTTP

HTTP HTTP

HTTPHTTP

HTTP

HTTPHTTP

HTTP

SSL / TLS

HTTPS

Web Server

HTTP - Hypertext Transfer Protocol

HTTP - Hypertext Transfer Protocol

application layer protocol

distributed, collaborative, hypermedia information systems

HTTP request-response protocol

1.0 a separate connection to the same

server to every resource request 1.1

reuse a connection

RFC 2616 (June 1999) :: HTTP/1.1 June 2014 :: retried & redefine RFC 7230, 7231, 7232, 7233, 7234, 7235

the inventor of the World Wide Web. He made a proposal for an information management system in March 1989,and he implemented the first successful communication between a Hypertext Transfer Protocol (HTTP) client and server via the Internet sometime around mid-November of that same year

Tim Berners-Lee

HTTP/2 (originally named HTTP/2.0) is the second major version of the HTTP network protocol used by the World Wide Web. It is based on SPDY. HTTP/2 is being developed by the Hypertext Transfer Protocol working group (httpbis, where bis means "repeat" or "twice") of the Internet Engineering Task Force. HTTP/2 would be the first new version of HTTP since HTTP 1.1, which was standardized in RFC 2616 in 1999. The Working Group presented HTTP/2 to IESG for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on Feb 17, 2015.

The standardization effort came as an answer to SPDY, an HTTP-compatible protocol developed by Google and supported in Chrome, Opera, Firefox, Internet Explorer 11, Safari, and Amazon Silk browsers.

HTTP Messages

Start LineZero or More Header Fields Followed by CRLF

Empty LineOptionally a Message-Body

Request or Response

REQUEST



RequestMethod SP Request-URI SP HTTP-Version CRLFex. GET /index.html HTTP/1.1

Method : GET Requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.)[1] The W3C has published guidance principles on this distinction, saying, "Web application design should be informed by the above principles, but also by the relevant limitations." HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. POST Requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.

GET /Squid/cgi-bin/cachemgr.cgi?server=localhost&port=3128&user_name=myuser&passwd=mypassword HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://localhost/Squid/cgi-bin/cachemgr.cgi Connection: keep-alive




Method : GET Requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.)[1] The W3C has published guidance principles on this distinction, saying, "Web application design should be informed by the above principles, but also by the relevant limitations." HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. POST Requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.

POST /Squid/cgi-bin/cachemgr.cgi HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://localhost/Squid/cgi-bin/cachemgr.cgi Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 76

server=localhost&host=localhost&port=3128&user_name=myuser&passwd=mypassword




Method : PUT Requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI. DELETE Deletes the specified resource. CONNECT Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy. OPTIONS Returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting ‘*' instead of a specific resource. TRACE Echoes back the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.

http://www.internetassignednumbersauthority.org/assignments/http-methods/http-methods.txt



Host: www.facebook.com Referer: http://www.google.com User-Agent: curl/7.37.1

http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

Request

RESPONSE



Response

Status Code : 1xx : Informational It means the request was received and the process is continuing. 2xx : Success It means the action was successfully received, understood, and accepted. 3xx: Redirection It means further action must be taken in order to complete the request. 4xx: Client Error It means the request contains incorrect syntax or cannot be fulfilled. 5xx: Server Error It means the server failed to fulfill an apparently valid request..

HTTP-Version SP Status-Code SP Reason CRLFex. HTTP/1.1 200 OK, HTTP/1.1 404 Not Found

http://www.internetassignednumbersauthority.org/assignments/http-status-codes/http-status-codes.txt



Response

ETag: “737060cd8c284d8af7ad3082f209582d"

An identifier for a specific version of a resource, often a message digest

HTTPSHTTP Over TLS , HTTP Over SSL

HTTPS

HTTP HTTPSSL

HTTPTLS

SSL/TLSTransport Layer Security

Secure Sockets Layer

SSL 1.0, 2.0 and 3.0 Netscape developed the original SSL protocols. Version 1.0 was never publicly released because of serious security flaws in the protocol; version 2.0, released in February 1995, "contained a number of security flaws which ultimately led to the design of SSL version 3.0". SSL version 3.0, released in 1996, represented a complete redesign of the protocol, produced by Paul Kocher working with Netscape engineers Phil Karlton and Alan Freier. Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historical document in RFC 6101.

Dr. Taher Elgamal, chief scientist at Netscape Communications from 1995 to 1998, is recognized as the "father of SSL".

As of 2014 the 3.0 version of SSL is considered insecure as it is vulnerable to the POODLE attack that affects all block ciphers in SSL; and RC4, the only non-block cipher supported by SSL 3.0, is also feasibly broken as used in SSL 3.0.

TLS 1.0 TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0. As stated in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0". TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security.

TLS 1.1 TLS 1.1 was defined in RFC 4346 in April 2006. It is an update from TLS version 1.0. Significant differences in this version include:

Added protection against cipher-block chaining (CBC) attacks. The implicit initialization vector (IV) was replaced with an explicit IV. Change in handling of padding errors.

Support for IANA registration of parameters.

TLS 1.2 TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification.

Symmetric-key algorithms are algorithms for cryptography that use the same cryptographic keys for both encryption of plaintext and decryption of ciphertext. The keys may be identical or there may be a simple transformation to go between the two keys.

PlainText Encrypt+

Decrypt+

CipherText PlainText

the same keys

Public-key cryptography, also known as asymmetric cryptography, is a class of cryptographic protocols based on algorithms that require two separate keys, one of which is secret (or private) and one of which is public. Although different, the two parts of this key pair are mathematically linked. The public key is used, for example, to encrypt plaintext or to verify a digital signature; whereas the private key is used for the opposite operation, in these examples to decrypt ciphertext or to create a digital signature.

Aliceprivate key

public keyBob

Alice BobEncrypt PlainTextCipherText

Alice

Decrypt PlainTextCipherTextAlice

PlainText Sign PlainTextAlice Signature

PlainTextAlice Signature

VerifyPlainTextAlice Signature

Alice

VALIDATION

DV (DOMAIN

VALIDATION)

Domain validation or DV certificates are verified according to the domain name. Typically, this is done by sending an email to an address listed in the WHOIS record from the domain. This is similar to an AV certificate, which is listed next, but it’s different in that a DV cert is intended to be used by SSL/TLS-enabled websites.

EV (extended validation)

With EV (extended validation) a Certificate Authority is going to use the “EV SSL Certificate Guidelines” that can be found in the CA/Browser Forum. While similar to an OV (organizational validation) certificate, this is separate and distinct from an OV SSL certificate.

OV SSL certificate, which refers to organization validation. For this type, the certificate authority will verify the actual business that is attempting to get the certificate. This is usually used by corporations, governments and others for SSL/TLS-enabled websites, code signing, as well as other uses.

OV (ORGANIZATION

VALIDATION)

GREEN BAR

Wildcard a wildcard certificate allows for unlimited subdomains to be protected with a single certificate. For example, you could use a wildcard certificate for the domain name opensrs.com and that cert would also work for mail.opensrs.com, ftp.opensrs.com and any other subdomain. The wildcard refers to the fact that the cert is provisioned for *.opensrs.com.

SAN (Subject Alternative Names) a SAN cert allows for multiple domain names to be protected with a single certificate. For example, you could get a certificate for opensrs.com, and then add more SAN values to have the same certificate protect opensrs.org, opensrs.net.

OPTION

http://opensrs.com

http://opensrs.net

HOW TO GET IT?

Sprivate key

public key

Application’s Information

CSR (Certificate Signing Request)

CA

+

CA

12

3Certificate

WHY WE MUST PAY FOR SIGNING?

Self-Signed Certificated

Sprivate key

public key

Application’s Information

CSR (Certificate Signing Request)

CA

+

CA

CA CA

CA

CA

CA

CACA

C HTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTP HTTPHTTP

HTTPHTTPHTTP S

SSL/TLS

asymmetricsymmetric ?

C HTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTP HTTPHTTP

HTTPHTTPHTTP S

SSL/TLS

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9

ProtocolVersion Random SessionID CipherSuite CompressionMethod

1

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9


1

CipherSuite • Key Exchange Algorithm • Cipher Algorithm • MAC Algorithm

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9


1

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9


2

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9

3

The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9

4

The ServerHelloDone message is sent by the server to indicate the end of the ServerHello and associated messages. After sending this message, the server will wait for a client response.

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9

5

Client compute “premaster key” from server and client random numbers.

Encrypt using “certificate”

Client and Server compute “master key” from the premaster key using an algorithm defined

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9

6

The ChangeCipherSpec message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys.

C S

ClientHello

ServerHello

Certificate

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished - Client

ChangeCipherSpec

Finished - Server

1

2

3

4

5

6

7

8

9

7

A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. It is essential that a change cipher spec message be received between the other handshake messages and the Finished message.

I NEED YOUR INFORMATION !!!

MitM / SSL StripMan in the Middle

C HTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTP HTTPHTTP

HTTPHTTPHTTP

C SHTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTPHTTPHTTP HTTP

HTTPHTTP

HTTP HTTPHTTPHTTP

HTTPHTTPHTTP

HTTP HTTPHTTP

HTTPHTTPHTTP

SSL/TLS

M

SSSL/TLS

HSTS - HTTP Strict Transport Security


HTTP - Hyper Text Transfer Protocol

Strict Transport SecurityHSTS - HTTP Strict Transport Security

HTTPS




IETF - Internet Engineering Task Force RFC 6797http://www.ietf.org/rfc.html


MECHANISM


Web Site


HTTP HTTPSHTTP

HTTP

HTTPS

HTTPHTTPS

HTTP

HTTPSHTTPSHTTP

HTTPHTTP

HTTP

HTTPS

HTTPS

HTTPS

HTTP

HTTPHTTP

HTTPSHTTPS

MECHANISM Web Site


Policy Enforcement

Web Site


Browser

HSTS

HTTP ClientUser-Agent

HTTPS

HTTP Response Header

“Strict-Transport-Security”Strict Transport Security Header Field max-age=??????? includeSubDomains

Web Site


HSTS

Strict-Transport-Security Browser

HTTP ClientUser-Agenthttphttps

example.com443

80 insecure : example.com

secure : example.com

www.example.com443

80 insecure : www.example.com

secure : www.example.com


https strict transport security

Technology