On the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain name
Most modern web browsers today sacrifice optimal TLS security for backward compatibility. They apply coarse-grained TLS configurations that support (by default) legacy versions of the protocol that have known design weaknesses, and weak ciphersuites that provide fewer security guarantees (e.g. non F...
| Main Authors: | , |
|---|---|
| Format: | Conference item |
| Published: |
Springer, Cham
2018
|
| _version_ | 1797078750691590144 |
|---|---|
| author | Alashwali, E Rasmussen, K |
| author_facet | Alashwali, E Rasmussen, K |
| author_sort | Alashwali, E |
| collection | OXFORD |
| description | Most modern web browsers today sacrifice optimal TLS security for backward compatibility. They apply coarse-grained TLS configurations that support (by default) legacy versions of the protocol that have known design weaknesses, and weak ciphersuites that provide fewer security guarantees (e.g. non Forward Secrecy), and silently fall back to them if the server selects to. This introduces various risks including downgrade attacks such as the POODLE attack [15] that exploits the browsers silent fallback mechanism to downgrade the protocol version in order to exploit the legacy version flaws. To achieve a better balance between security and backward compatibility, we propose a mechanism for fine-grained TLS configurations in web browsers based on the sensitivity of the domain name in the HTTPS request using a whitelisting technique. That is, the browser enforces optimal TLS configurations for connections going to sensitive domains while enforcing default configurations for the rest of the connections. We demonstrate the feasibility of our proposal by implementing a proof-of-concept as a Firefox browser extension. We envision this mechanism as a built-in security feature in web browsers, e.g. a button similar to the “Bookmark” button in Firefox browsers and as a standardised HTTP header, to augment browsers security. |
| first_indexed | 2024-03-07T00:36:14Z |
| format | Conference item |
| id | oxford-uuid:818122b8-aa5c-4a4e-8c56-14cd8cf270e1 |
| institution | University of Oxford |
| last_indexed | 2024-03-07T00:36:14Z |
| publishDate | 2018 |
| publisher | Springer, Cham |
| record_format | dspace |
| spelling | oxford-uuid:818122b8-aa5c-4a4e-8c56-14cd8cf270e12022-03-26T21:30:43ZOn the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain nameConference itemhttp://purl.org/coar/resource_type/c_5794uuid:818122b8-aa5c-4a4e-8c56-14cd8cf270e1Symplectic Elements at OxfordSpringer, Cham2018Alashwali, ERasmussen, KMost modern web browsers today sacrifice optimal TLS security for backward compatibility. They apply coarse-grained TLS configurations that support (by default) legacy versions of the protocol that have known design weaknesses, and weak ciphersuites that provide fewer security guarantees (e.g. non Forward Secrecy), and silently fall back to them if the server selects to. This introduces various risks including downgrade attacks such as the POODLE attack [15] that exploits the browsers silent fallback mechanism to downgrade the protocol version in order to exploit the legacy version flaws. To achieve a better balance between security and backward compatibility, we propose a mechanism for fine-grained TLS configurations in web browsers based on the sensitivity of the domain name in the HTTPS request using a whitelisting technique. That is, the browser enforces optimal TLS configurations for connections going to sensitive domains while enforcing default configurations for the rest of the connections. We demonstrate the feasibility of our proposal by implementing a proof-of-concept as a Firefox browser extension. We envision this mechanism as a built-in security feature in web browsers, e.g. a button similar to the “Bookmark” button in Firefox browsers and as a standardised HTTP header, to augment browsers security. |
| spellingShingle | Alashwali, E Rasmussen, K On the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain name |
| title | On the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain name |
| title_full | On the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain name |
| title_fullStr | On the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain name |
| title_full_unstemmed | On the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain name |
| title_short | On the feasibility of fine-grained TLS security configurations in web browsers based on the requested domain name |
| title_sort | on the feasibility of fine grained tls security configurations in web browsers based on the requested domain name |
| work_keys_str_mv | AT alashwalie onthefeasibilityoffinegrainedtlssecurityconfigurationsinwebbrowsersbasedontherequesteddomainname AT rasmussenk onthefeasibilityoffinegrainedtlssecurityconfigurationsinwebbrowsersbasedontherequesteddomainname |