I'm here trying to connect a Linux Ubuntu VPC Machine to Azure Cloud network interface, only thing I can't suss out is how to config my IKE and ESP at my end to match the Below -
IKEv2 Encryption | GCMAES256, AES256
IKEv2 Integrity | GCMAES256, SHA384, SHA256, SHA1
DH Group | DHGroup2
IPsec Encryption | GCMAES256, AES256
IPsec Integrity | GCMAES256, SHA256
PFS Group | None, PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1
Every variation I've tried so far
#ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
#ike=3des-sha1-modp1024!
ike=aes256-sha256-modp1024,aes256-sha1-modp1024!
#esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
#esp=aes256-sha256-modp1024!
esp=aes256-sha256-modp1024!
I've tried to follow and decipher things from -> https://docs.strongswan.org/docs/5.9/config/IKEv2CipherSuites.html but I can't figure out which ones to use
You can use the below given combination of key exchanges, hashing, authentication, and encryption algorithms or cipher suites that ‘Strongswan’ allows for different clients to use: -
ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
Ensure that the ‘IPSec.conf.inc’ in the ubuntu VM is configured with the above stated cipher suites since according to the link that you have given for ‘Strongswan’, the IKEv2 encryption cipher suite to be used should have encryption ‘x b w o g a’ scheme for the Ubuntu Linux VM’s VPN client.
• Also, ensure to use the ‘Commercial National Security Algorithm Suite’ which specifies the algorithm parameters given as below: -
Encryption
AES with 256-bit key length (aes256gcm16 or aes256)
Key Exchange
ECDH with NIST P-384 curve (ecp384)
DH with at least 3072-bit modulus (modp3072 or higher)
Pseudo-Random Function/Integrity Protection
SHA-384 (e.g. prfsha384 or sha384 if not using AES in GCM mode)
Digital Signatures
ECDSA with NIST P-384 curve
RSA with at least 3072-bit modulus
This would include all the required encryption and algorithm parameters as stated by you through the Azure cloud network interface.
• Also, please refer to the below image which represents the implementation of IPSec gateways in host-to-host scenarios which clearly shows the IPSec VPN key exchange implementation scenarios: -
Please refer to the below links for more information on this: -
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-20-04
https://sysadmins.co.za/setup-a-site-to-site-ipsec-vpn-with-strongswan-on-ubuntu/
Related
While studying how https works, ssl handshake in https, following points were raised without getting complete answer.
In the flow of https, how client upon receiving server certificate validates its authenticity using digital signature in server certificate and public key of CA certificate.
May anyone explain this in brief?
In brief the idea of asymmetric cryptography is that you can encrypt with one key and decrypt with another key. The idea of digital signature is that you can encrypt with private key and decrypt with public key.
So when CA issues certificate for server it encodes some fields of certificate (described in specification):
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
in DER format and then encrypts it with its private key using signatureAlgorithm. When browser receives server certificate it takes the same fields in DER format then it takes CA public key and decrypts the encrypted signature of certificate using signatureAlgorithm.
If they match, that means that the certificate was really signed by CA and it can be trusted.
I'm using Yubikey4 as my smart card with my StartCom Class 1 login certificate. My problem is: windows don't want to use this card.
Windows credential manager: "No valid certificates were found on this smart card".
Microsoft office doesn't see this card.
Windows VPN: "A certificate could not be found that can be used with this Extensible Authentication Protocol."
Keepass2 (RSA Certificate Key Provider plugin - uses windows security): "No cerficiate available. No certificates meets the application criteria." (of course tested with RSA certificate too).
My certificate details:
Key Usage: Digital Signature, Key Encipherment, Data Encipherment (b0)
Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2), Secure Email (1.3.6.1.5.5.7.3.4)
Public key parameters: ECDH_P384
From device manager:
Smart card name: "Identity Device (NIST SP 800-73 [PIV])"
Smart card reader name: "Microsoft Usbccid Smartcard Reader (WUDF)"
Is there any key usage required for smart card usage?
Your Device Manager indicates that you are using the Microsoft Minidriver for the smartcard. According to the Yubikey Basic Troubleshooting Guide this problem can be caused by using these minidrivers for the smartcard rather than the Yubico minidrivers.
You can install the driver following this guide: https://support.yubico.com/hc/en-us/articles/360015654560-Deploying-the-YubiKey-Minidriver-to-Workstations-and-Servers.
I like to transmit data from multiple sources to one target collectd server, but I'm not sure, how to ensure, that at the same time:
data is encrypted, i.e. no need to trust the network
data is signed, i.e. the target can trust the sources
no source shares the credentials with other sources
However, in the network plugin, so far I found only the values sign or encrypt for SecurityLevel, but not both. And it seems, that I cannot have different credentials (Username + Password) for different sources. Maybe I just misunderstood collectd?
There are 2 questions.
1) Encryption vs. signing
SecurityLevel "sign" provides sender verification.
SecurityLevel "encrypt" provides both encryption and sender verification.
In private/public keys schemes signing and encryption are separate: you can sign without encrypting, or encrypt without signing. However collectd uses a shared-secret scheme: both encryption and signing guarantee that the sender knows the shared secret: the sender is always verified.
2) Multiple credentials
You can have different credentials for different sources. See the following sample configuration.
<Plugin "network">
<Listen "192.168.0.1">
SecurityLevel "Encrypt"
AuthFile "/etc/collectd/auth_file"
</Listen>
</Plugin>
Where /etc/collectd/auth_file contains credentials using the following format.
user1: password1
user2: password2
References: https://collectd.org/wiki/index.php?title=Networking_introduction
I'm asking this question in order for be 100% sure.
link
To validate the certificate to ensure it contains the information
digitally signed by the certificate authority, the web browser
verifies the digital signature. Because the digital signature is an
encrypted hash value that was computed based on the contents of the
certificate, the web browser needs to compare hash values. The web
browser computes a hash value based on the contents of the certificate
it received. It then decrypts the digital signature to determine the
hash value that the certificate authority computed. If the two hash
values match, the web browser is assured that the certificate contains
the information that the certificate authority verified and digitally
signed.
questions :
The web browser computes a hash value based on the contents of the
certificate it received
The browser knows in which digest algorithm the certificate was used inside , so he uses it also to calculate a hash - based on the certificate content.
It then decrypts the digital signature to determine the hash value
that the certificate authority computed
The browser knows which CA created the certificate , so he takes the public key from the appropriate computer store location and apply it on the encrypted hash value . the result is the decrypted hash value.
It then see if both the same.
Am I right ?
(You may be interested in this question on Security.SE.)
This is the structure of an X.509 certificate:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
When presented with the certificate, the browser gets the signature algorithm from the certificate itself. Typically, this is something like RSAwithSHA1.
In this case, it can indeed recalculate the SHA-1 digest of the TBSCertificate (the actual content of the certificate).
In addition, from the TBSCertificate, it can find the issuer name: this is what's used to find a trust anchor from the known CA certificates (the issuer name must match the subject of the CA certificate). When it has found the CA certificate with the right name in the list it already trusts, it can get the public RSA key from that CA certificate.
Having both the SHA-1 digest and the RSA public key, it can verify that the signatureValue matches.
the digital signature is an encrypted hash value
That's not strictly true, although it's commonly said. Digital signatures are digital signatures, not encryption.
The problem is that RSA uses the same maths to encrypt and sign: encryption with the public key and signature with the private key. Often, one is confused with the other (even in the OpenSSL API). It doesn't make sense to "encrypt" with a private key, since "encrypting" implies hiding (and you're not hiding anything if you're giving the public key away so the it can "decrypt" the signature).
This subtly about hash and encryption with digital signatures wouldn't work with some other algorithms such as DSA, which are for signatures only.
This is why a number of digital signature APIs combine the hash and key usage into a single "sign" or "verify" operation. This is what the Java Signature API does, for example: you tell it to use RSAwithSHA1 or DSAwithSHA1, give it the key and the message, and tell it to sign or verify, you don't have to do the digest or "encryption" manually.
For the purpose of certificate verification: the browser gets the issuer from the cert and find the corresponding public key (from trusted CA certs), it also gets the signature algorithm from the cert, and then verifies the signature with that public key and the TBSCertificate content, according to what the signature algorithm dictates.
These two actions seem to do the same:
using the Basic Constraints extension in a X.509 Certificate to signify that it is a CA certificate and
using the Key Usage extension e.g. to signify that the public key can be used for certificate signining.
What is the difference between these extensions?
Do they serve same purpose or complement each other?
"Key Usage" defines what can be done with the key contained in the certificate. Examples of usage are: ciphering, signature, signing certificates, signing CRLs.
"Basic Constraints" identifies if the subject of certificates is a CA who is allowed to issue child certificates.
For a certificate that can be used to sign certificates, the info is in some sense duplicated:
X509v3 Basic Constraints: CA: TRUE --- Can sign certificates
X509v3 Key Usage: Key Cert Sign --- Can sign certificates
But "Basic Constraints" will also specify the maximum depth of valid certification chain.
Though it is duplicated, you need to specify both, according to RFC 3280 --- X.509.
This is the relevant paragraph from the RFC (page 29):
The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (section 4.2.1.10) MUST also be asserted.
Key Usage describes intended purposes of the certificate.
Basic Constraints extension describes how deep the certificate chain that has the certificate as it's top can be. In other words, this extension is used by CAs to restrict activity of their sub-CAs when the sub-CA certificate is issued. If toplevel CA gets a sub-CA , it allows sub-CA to issue end-user certificates, but doesn't allow sub-CA have it's own sub-CAs.