Todd A. Jacobs | Pragmatic CybersecurityTopics like #cybersecurity and #encryption are difficult to talk about plainly because they are complex. While it's usefully reductionist to tell users that HTTPS is more secure than unencrypted HTTP, it can also lead to oversimplification (and thus a lack of adequate #infosec funding) when designing and implementing #securitycontrols. Consider the following excerpted information I recently shared in one of the LinkedIn communities when trying to explain why a URL or TCP/IP socket by itself doesn't create a secure connection.
The "HTTPS" in a URL is a URI scheme that is interpreted by the browser as an instruction to establish a TLS connection over which the HTTP protocol can be be negotiated. The actual TCP/IP transport layer handshake, TLS and HTTP protocol negotiations, and encrypted payload communications between client and server are handled in other layers.
Useful References
Hypertext, URIs, and Schemes
: https://www.rfc-editor.org/rfc/rfc9110#section-4.2.2
: https://www.rfc-editor.org/rfc/rfc8820#name-uri-schemes
: https://en.wikipedia.org/wiki/List_of_URI_schemes
TLS (sometimes still referred to as "SSL" for historical reasons)
: https://www.rfc-editor.org/rfc/rfc8446
RFC 9110: HTTP Semantics
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.