Hi Ravi, locally loaded certificate are always trusted even if the X.509 trustchain is not complete. This also allows the use of self-signed certificates.
Regards Andreas On 05.01.2018 14:10, Ravikumar Chennaparapu wrote: > Hi Andreas, > > We did some analysis and observed that issue is only seen if we use same > certificates on both sides. > > We observed that when verify_trust_chain invokes issued_by, it is always > referencing local certificate instead the peer certificate which is > tampered. > > Local certificate is valid one so validation is successful and tunnel > got established with tampered peer certificate.(only certificate > signature content is modified). > > Could you check this from your side. If needed more info regarding this > issue, please let me know. > > Thanks and Regards, > Ravi > > > > > > On Thu, Jan 4, 2018 at 5:49 PM, Ravikumar Chennaparapu > <[email protected] <mailto:[email protected]>> wrote: > > Hi Andreas, > > Thanks for the quick reply. > > Could you point out the code where peer remote cert validation > happens for CERT payload? > > Regards, > Ravi > > > > On Thu, Jan 4, 2018 at 2:18 AM, Andreas Steffen > <[email protected] > <mailto:[email protected]>> wrote: > > Hi Ravi, > > we are not adding received certificates to any trusted cache. > Per default remote certificates are never trusted and are > temporarily > added to the auth_cfg object of the IKE_SA. Full X.509 trust chain > verification then happens at a later stage. > > Regards > > Andreas > > > On 03.01.2018 14:47, Ravikumar Chennaparapu wrote: > > Hi, > > We found an issue with strongswan 5.2.2; peer is accepting > CERT payload > even though digital signature field in CERT payload is > tampered. > > As per the below code, there is no validation for the peer's > pub key > certificate; peer's public key is added to the cache without any > validation. We do see this as a security vulnerability, > could you check > this? Is our understanding correct ? > > > static void process_x509(cert_payload_t *payload, auth_cfg_t > *auth, > cert_encoding_t encoding, bool *first) > { > certificate_t *cert; > char *url; > > cert = try_get_cert(payload); > if (cert) > { > if (*first) > { /* the first is an end entity certificate */ > DBG1(DBG_IKE, "received end entity cert \"%Y\"", > cert->get_subject(cert)); > auth->add(auth, AUTH_HELPER_SUBJECT_CERT, cert); > *first = FALSE; > } > else > { > DBG1(DBG_IKE, "received issuer cert \"%Y\"", > cert->get_subject(cert)); > auth->add(auth, AUTH_HELPER_IM_CERT, cert); > } > } > else if (encoding == ENC_X509_HASH_AND_URL) > { > /* we fetch the certificate not yet, but only if > * it is really needed during authentication */ > url = payload->get_url(payload); > if (!url) > { > DBG1(DBG_IKE, "received invalid hash-and-url " > "encoded cert, ignore"); > return; > } > url = strdup(url); > if (*first) > { /* first URL is for an end entity certificate */ > DBG1(DBG_IKE, "received hash-and-url for end entity cert > \"%s\"", > url); > auth->add(auth, AUTH_HELPER_SUBJECT_HASH_URL, url); > *first = FALSE; > } > else > { > DBG1(DBG_IKE, "received hash-and-url for issuer cert > \"%s\"", url); > auth->add(auth, AUTH_HELPER_IM_HASH_URL, url); > } > } > } > > Thanks and Regards, > Ravi > > > -- > ====================================================================== > Andreas Steffen > [email protected] > <mailto:[email protected]> > strongSwan - the Open Source VPN Solution! > www.strongswan.org <http://www.strongswan.org> > Institute for Networked Solutions > University of Applied Sciences Rapperswil > CH-8640 Rapperswil (Switzerland) > ===========================================================[INS-HSR]== > > > -- ====================================================================== Andreas Steffen [email protected] strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[INS-HSR]==
smime.p7s
Description: S/MIME Cryptographic Signature
