|Maintainer||Vincent Hanquez <email@example.com>|
- ciphersuite_all :: [Cipher]
- ciphersuite_medium :: [Cipher]
- ciphersuite_strong :: [Cipher]
- ciphersuite_unencrypted :: [Cipher]
- cipher_null_null :: Cipher
- cipher_null_SHA1 :: Cipher
- cipher_null_MD5 :: Cipher
- cipher_RC4_128_MD5 :: Cipher
- cipher_RC4_128_SHA1 :: Cipher
- cipher_AES128_SHA1 :: Cipher
- cipher_AES256_SHA1 :: Cipher
- cipher_AES128_SHA256 :: Cipher
- cipher_AES256_SHA256 :: Cipher
- certificateVerifyChain :: [X509] -> IO Bool
- certificateVerifyAgainst :: X509 -> X509 -> IO Bool
- certificateVerifyDomain :: String -> [X509] -> Bool
Cipher related definition
all encrypted ciphers supported ordered from strong to weak. this choice of ciphersuite should satisfy most normal need
this is not stricly a usable cipher; it's the initial cipher of a TLS connection
AES cipher (128 bit key), RSA key exchange and SHA256 for digest
AES cipher (256 bit key), RSA key exchange and SHA256 for digest
verify a certificates chain using the system certificates available.
each certificate of the list is verified against the next certificate, until it can be verified against a system certificate (system certificates are assumed as trusted)
This helper only check that the chain of certificate is valid, which means that each items received are signed by the next one, or by a system certificate. Some extra checks need to be done at the user level so that the certificate chain received make sense in the context.
for example for HTTP, the user should typically verify the certificate subject match the URL of connection.
TODO: verify validity, check revocation list if any, add optional user output to know the rejection reason.
verify a certificate against another one. the first certificate need to be signed by the second one for this function to succeed.