This document outlines important security considerations when using OpenSSL-WASM-JS in web applications.
- Overview
- WebAssembly Security Model
- Cryptographic Considerations
- Browser Environment Limitations
- Best Practices
- Known Limitations
- Reporting Security Issues
OpenSSL-WASM-JS provides cryptographic functionality in web browsers through WebAssembly. While this enables powerful cryptographic operations directly in the browser, it also introduces specific security considerations that developers should be aware of.
WebAssembly runs in a sandboxed environment within the browser with the following security properties:
-
Memory Isolation: WebAssembly modules have their own linear memory that is not directly accessible from JavaScript without explicit exports.
-
No Direct System Access: WebAssembly code cannot directly access the file system, network, or other system resources.
-
Same-Origin Policy: WebAssembly modules are subject to the same-origin policy enforced by browsers.
-
Deterministic Execution: WebAssembly execution is deterministic, which helps prevent certain types of side-channel attacks.
However, WebAssembly is not immune to all security concerns:
-
Side-Channel Attacks: Timing attacks may still be possible depending on the implementation.
-
Memory Safety: While WebAssembly provides memory isolation from the host, memory safety within the WebAssembly module depends on the compiled code.
In a browser environment, secure random number generation is critical for cryptographic operations. OpenSSL-WASM-JS addresses this by:
-
Using the browser's cryptographically secure random number generator (
crypto.getRandomValues()
) when available. -
Falling back to OpenSSL's RAND functions, which have been patched to work in the WebAssembly environment.
Browser environments present unique challenges for key management:
-
Storage: Private keys stored in browser storage (localStorage, IndexedDB) are vulnerable if the device is compromised.
-
Memory Exposure: Keys in memory might be exposed through browser memory dumps or if the page is cached.
-
Cross-Origin Risks: Ensure cryptographic operations are performed in a secure context to prevent cross-origin attacks.
The browser environment imposes several limitations on cryptographic operations:
-
No Access to System Entropy Sources: Unlike native OpenSSL, the WebAssembly version cannot access system entropy sources like
/dev/urandom
. -
Performance Constraints: Cryptographic operations may be slower in WebAssembly compared to native code.
-
Feature Limitations: Some OpenSSL features that depend on system resources (like hardware acceleration) are not available.
When using OpenSSL-WASM-JS in your applications:
-
Always Use HTTPS: Ensure your application is served over HTTPS to prevent man-in-the-middle attacks.
-
Content Security Policy: Implement a strict Content Security Policy to prevent XSS attacks that could compromise cryptographic operations.
-
Subresource Integrity: Use Subresource Integrity (SRI) when loading the library from a CDN.
-
Key Generation: Generate keys with sufficient entropy and appropriate key lengths.
-
Secure Key Storage: Consider using the Web Crypto API's
CryptoKey
objects withnon-extractable
set totrue
for sensitive keys. -
Ephemeral Keys: Use ephemeral keys when possible and avoid storing private keys in browser storage.
-
Salt and IV Management: Always use unique salts and initialization vectors for each encryption operation.
Secure key generation:
// Generate a secure AES-256 key
const key = openssl.randomBytes(32);
// Use the key for encryption
const encrypted = openssl.aesEncrypt(data, key, iv);
Proper IV handling:
// Generate a unique IV for each encryption
const iv = openssl.randomBytes(16);
// Store the IV with the ciphertext (it doesn't need to be secret)
const encrypted = openssl.aesEncrypt(data, key, iv);
const result = {
iv: openssl.toHex(iv),
ciphertext: openssl.toHex(encrypted)
};
OpenSSL-WASM-JS has the following security limitations:
-
No Hardware Security Module Support: Cannot interface with HSMs or secure enclaves.
-
Limited Protection Against Side-Channel Attacks: The WebAssembly environment may not fully protect against timing attacks or other side-channel vulnerabilities.
-
Memory Management: WebAssembly memory is subject to garbage collection by the browser, which may leave sensitive data in memory longer than necessary.
If you discover a security vulnerability in OpenSSL-WASM-JS, please follow these steps:
-
Do Not Disclose Publicly: Please do not disclose the issue publicly until it has been addressed.
-
Contact the Maintainers: Send an email to security@example.com with details of the vulnerability.
-
Provide Details: Include steps to reproduce, potential impact, and any suggested mitigations.
We take security issues seriously and will respond as quickly as possible.