Files
AnyPS5/docs/dev/debt/libSceSsl.md
T
Claude e37137241d feat(ssl): run TLS 1.2 client connections over Mbed TLS
sceSslConnect performs the client handshake on the host socket that the
guest number maps to in the libkernel or libSceNet socket table, and
sceSslRead and sceSslWrite carry application data. Session state comes
from the context's memory pool, and the server is verified against the
CAs loaded with sceSslLoadCert; a loaded client certificate is sent when
the server asks for one.

libkernel exports KernelLookupSocketNative_nid_no_patch, which checks
its own socket table before the one libSceNet registers. Pools take a
lock so connections can allocate outside the library lock.

TLS 1.3 is compiled out. A missing CA, a verify callback, would-block
sockets and every failure whose console code is unknown throw, as
recorded in the libSceSsl debt entry.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01RoU3ZF76A6uR8sCA7NMLch
2026-10-16 11:37:32 +00:00

6.5 KiB

libSceSsl technical debt

Unknown function info

  • sceSslCreateConnection, sceSslDeleteConnection, sceSslSetVerifyCallback, sceSslConnect, sceSslRead, sceSslWrite (libSceSsl) - imported by ffmpeg.prx. Signatures follow SharpProspero, which also says the socket stays open after sceSslDeleteConnection and that sceSslRead returns 0 at the end of the stream. An unknown context returns SSL_ERROR_INVALID_ID (0x8095F006), as sceSslGetMemoryPoolStats does on the console and as KytyPS5 and sharpemu return for other context calls; for an unknown connection, a connection whose context was terminated and a null host the console's codes are unknown, so these throw. sceSslConnect runs a TLS 1.2 client handshake with Mbed TLS 3.6.7 over the host socket that the guest number maps to in the libkernel or libSceNet socket table, and sceSslRead and sceSslWrite carry application data over it. TLS 1.3 is compiled out: SharpProspero's SceSslVersion ends at TLS 1.2, and Mbed TLS 1.3 needs PSA crypto state that is process-wide rather than allocated from a context's pool. Connection state is allocated from the context's pool and returned to it by sceSslDeleteConnection; a connection keeps the pool alive after sceSslTerm. The server is verified against the CAs loaded with sceSslLoadCert: chain, validity dates and the host name the connection was created with, which is also sent as SNI. A client certificate loaded with sceSslLoadCert is sent when the server asks for one. With no CA loaded sceSslConnect throws, because no root bundle is shipped and the console's built-in roots are unknown. With a verify callback set it throws: SharpProspero describes the arguments as an id, bits saying what failed, the chain, its length and the user argument, with a negative return failing the handshake with that value, but whether the id is the context or the connection, the bit values, the chain element type and when the callback runs are unknown. Handshake, verification and socket failures, a second sceSslConnect, a read or write before the handshake, a descriptor that is not a socket, a null buffer, write flags other than 0 and read flags other than 0 and MsgFlagPartialRead (1) throw, as their console codes are unknown; MsgFlagPeek (3) is not implemented. A non-blocking socket that would block throws, and so does a libSceNet socket whose SO_RCVTIMEO or SO_SNDTIMEO expires, as libSceNet sets them on the host socket; libkernel keeps them above the host socket, so they do not bound SSL reads and writes on a libkernel socket. sceSslRead returns what one Mbed TLS read delivers, up to len, with flags 0 and with MsgFlagPartialRead alike; SharpProspero describes sceSslRead as reading up to len but MsgFlagPartialRead as returning before the buffer is full, so whether flags 0 waits to fill the buffer is unknown. It returns 0 after the server's close_notify and also when the transport ends without one. sceSslWrite sends all of len, capped at INT_MAX, and returns the count. A connection serializes its reads and writes, so a read blocked in one thread holds back a write on the same connection from another. sceSslDeleteConnection sends no close_notify. The socket is not checked when the connection is created, sceSslTerm leaves the context's connections to sceSslDeleteConnection, and sceSslSetVerifyCallback accepts any callback, null included, and returns 0. None of this is verified on the console. SSL_ERROR_BEFORE_INIT (0x8095F001) is never returned, as the library keeps no state apart from its contexts
  • sceSslClose (libSceSsl) - unknown signature
  • sceSslGetSerialNumber (libSceSsl) - unknown signature
  • sceSslLoadCert, sceSslGetCaList, sceSslFreeCaList, sceSslGetCaCerts, sceSslFreeCaCerts, sceSslUnloadCert (libSceSsl) - signatures and layouts follow SharpProspero. PPSA15508/01.002.000 calls sceSslLoadCert with one 1,408-byte PEM CA and null client certificate/key arguments; this confirms that call shape, not console error behavior. Mbed TLS 3.6.7 parses DER/PEM chains and checks an optional client certificate/key pair. Imports are retained per context and committed together; a failed import preserves existing credentials. CA queries return independently owned snapshots; unload clears active credentials while outstanding snapshots remain valid. Appending repeated CA imports, snapshot lifetime across unload, memory overhead and error precedence have not been measured on a PS5. Invalid loads, malformed material, exhausted pools and unsupported keys throw rather than inventing console error codes. No root bundle is shipped; an empty context still returns NOT_FOUND. The existing null-list error, unknown-context behavior and legacy clearing of foreign raw CA lists remain unchanged. Certificate readers remain unimplemented. Loading credentials does not start a TLS connection; sceSslConnect verifies the server against the loaded CAs and offers the loaded client certificate
  • PPSA01317 imports declared without parameters, signatures unknown: sceSslDisableVerifyOption, sceSslGetAlpnSelected, sceSslSetAlpn, sceSslSetMinSslVersion (libSceSsl). Connection storage exists, but their signatures and option behavior remain unknown, so they still throw

Functional