Private keys are generated exclusively on your system, and never on the SSLMate servers. Private keys are stored on your filesystem using restrictive file permissions (600) by default.
When you use the sslmate command line program, private keys are never transmitted to or stored by the SSLMate servers.
When you use the web console, private keys are generated by your web browser using WebCrypto and are never transmitted to or stored by the SSLMate servers.
When you use sslmate-agent, private keys are synchronized with other instances of sslmate-agent in your cluster using end-to-end encryption. Only the holder of your secret cluster key can reverse the encryption and recover your private key. Cluster keys are generated exclusively on your system, and are never transmitted to or stored by the SSLMate servers. Therefore, SSLMate can never see your private keys.
Technical details: Keys are generated using a cryptographically-secure pseudo-random number generator (specifically, crypto/rand from Go's standard library). Encryption is performed with the NaCl symmetric secret box construction, which uses XSalsa20 for encryption and Poly1305 for authentication. The 256-bit symmetric secret box key is derived from your 256-bit secret cluster key using HKDF. The 192-bit nonce is randomly generated using a cryptographically-secure pseudo-random number generator and prepended to the encrypted message. We use the NaCl and HKDF implementations from Go's x/crypto library; we don't roll our own crypto.
The SSLMate client software is open source and can be audited to verify that these assertions are true.
The SSLMate website and the SSLMate API endpoint are accessible over HTTPS only, and SSLMate servers are configured to prefer strong, forward secure ciphers. Strict Transport Security (HSTS) is used to ensure that web browsers use only HTTPS to contact SSLMate, and sslmate.com is included in the HSTS preload list.
The SSLMate client communicates with SSLMate over HTTPS and correctly validates the server's SSL certificate.
You may optionally integrate SSLMate with your accounts at other providers, so that SSLMate can automatically publish DNS records or discover domains to monitor. All requests to your third-party account are proxied through a hardened service which verifies and logs the request before sending it to the third-party provider. The main SSLMate backend has no access to your credentials. Read more
All SQL is executed with prepared statements to eliminate SQL injection. All HTML is generated with context-aware templating engines (either XSLT or Go's html/template library) to eliminate XSS vulnerabilities. Credentials are stored separately from source code. We carefully choose and audit our third-party dependencies, and monitor them for security advisories and new releases.
Credit card information
SSLMate does not store credit card details. We out source our credit card processing to Stripe, who comply with PCI standards. Credit card details are securely transmitted to Stripe directly from your web browser and never pass through our servers.
Account passwords are stored securely using a one-way key derivation algorithm (PBKDF2 with 25,000 rounds of HMAC-SHA256). If you request a password reset, a temporary token will be randomly generated and emailed to you.
Servers run only stable operating systems with software that receives automatic security updates. Services are kept to a minimum to reduce the attack surface.
Servers are configured using configuration management to ensure the uniformity of security-sensitive configuration. Our configuration management repository is encrypted and signed to protect sensitive credentials and prevent unauthorized configuration changes.
All communication between internal systems, such as database traffic, travels over a VPN, TLS, or SSH. All systems used for development and administration use full disk encryption to protect keys and credentials.
Reporting a security issue
SSLMate investigates all reported security issues and credits security researchers who report vulnerabilities to us. If you believe you've found a security vulnerability in any aspect of SSLMate's software or services, please send an email to firstname.lastname@example.org (optionally using our PGP key), with as much information as possible about the potential flaw. You will receive a response as soon as possible, usually within 24 hours.
We will not bring legal action against you for engaging in Good Faith Security Research. Good Faith Security Research is accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.
Please note that the following are not considered security issues:
Clickjacking when logged out - Since it is not possible to perform security-sensitive actions when logged out, and there are legitimate uses for framing, SSLMate does not send an
X-Frame-Optionsheader when logged out. We do send a restrictive
X-Frame-Optionsheader when logged in, as well as on the login, signup, and password reset pages. If you find an actual security vulnerability due to clickjacking, please let us know. However, the mere lack of an
X-Frame-Optionsheader on some pages does not constitute a security vulnerability.
Content-Security-Policyheader - Since our templating engine does not allow the injection of unescaped HTML, developing a Content Security Policy has a lower priority than other security work. If you find an actual security vulnerability such as XSS, please let us know. However, the mere lack of a
Content-Security-Policyheader does not constitute a security vulnerability.
Disabled XSS filter/auditor - Since the XSS filter/auditor can introduce new vulnerabilities, and since our templating engine does not allow the injection of unescaped HTML, we disable the XSS filter/auditor by sending the
X-XSS-Protection: 0header. If you find an actual XSS vulnerability, please let us know. However, the mere disabling of the XSS filter/auditor does not constitute a security vulnerability.
p=noneDMARC Policy - Many SSLMate customers use a mailing list as the contact address for their SSLMate account, and a restrictive DMARC policy would prevent them from receiving vital notifications, including alerts about security-critical certificate problems. Although
p=nonemight make it easier for phishers to spoof email from
sslmate.com, phishing is better prevented with phishing-proof security keys, which SSLMate supports.
- Lack of CAPTCHAs - Since CAPTCHAs are user-hostile, SSLMate does not use them. We accept that this allows automated submission of forms.
- 0462 D7AE 9C2D 5919 269D 2559 3F5F 56F0 7DDA D2F8 — for encrypting/signing correspondence and certifying other keys
- 3EC7 49BE 801F DAF1 3A0C 2883 426F 7E4D B60B BFB8 — for signing individual software releases
- E26A C6CD 4817 CB4F 2F68 9493 CAC6 645E 0790 C4BB — for signing software repository indexes (e.g. APT)
- Shivam Kumar Agarwal - reported that SSLMate did not invalidate other login sessions when changing an account's password.
- Evan Ricafort - @evanricafort - reported that SSLMate did not invalidate password reset tokens when changing an account's password.
- Mubassir Kamdar - reported that the performance of SSLMate's password hashing implementation degraded with long passwords.
- Gamiel Xavier V. Manbiotan - reported that SSLMate did not invalidate password reset tokens when changing an account's email address.
- Anonymous and Suyog Palav - reported that the password reset page was not rate-limited.