75 Matching Annotations
  1. Sep 2023
  2. Jul 2023
  3. May 2023
    1. 🥳

      ```js import { connect } from 'cloudflare:sockets';

      export default { async fetch(req: Request) { const gopherAddr = "gopher.floodgap.com:70"; const url = new URL(req.url);

      try {
        const socket = connect(gopherAddr);
      
        const writer = socket.writable.getWriter()
        const encoder = new TextEncoder();
        const encoded = encoder.encode(url.pathname + "\r\n");
        await writer.write(encoded);
      
        return new Response(socket.readable, { headers: { "Content-Type": "text/plain" } });
      } catch (error) {
        return new Response("Socket connection failed: " + error, { status: 500 });
      }
      

      } }; ts connect(address: SocketAddress | string, options?: SocketOptions): Socket

      declare interface Socket { get readable(): ReadableStream; get writable(): WritableStream; get closed(): Promise<void>; close(): Promise<void>; startTls(): Socket; }

      declare interface SocketOptions { secureTransport?: string; allowHalfOpen: boolean; }

      declare interface SocketAddress { hostname: string; port: number; } ```

  4. Apr 2023
    1. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS.
    1. The rest of the URL (/path/?some=parameters&go=here) has no business being inside ClientHello since the request URL is a HTTP thing (OSI Layer 7), therefore it will never show up in a TLS handshake (Layer 4 or 5). That will come later on in a GET /path/?some=parameters&go=here HTTP/1.1 HTTP request, AFTER the secure TLS channel is established.
  5. Mar 2023
  6. Jan 2023
  7. Dec 2022
  8. Mar 2022
  9. Feb 2022
  10. Dec 2021
  11. Oct 2020
    1. I want to run docker daemon with TLS enabled but client certificate authentication disabled so that clients can verify authenticity of docker daemon but docker daemon doesn't need to verify clients.
  12. Mar 2020
  13. Dec 2019
  14. Apr 2019
  15. Nov 2018
  16. Oct 2018
    1. This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.
  17. Sep 2018
    1. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.