Recommended
More Related Content
What's hot
What's hot (20)
Similar to Certificate pinning v certificate transparency
Similar to Certificate pinning v certificate transparency (20)
Certificate pinning v certificate transparency
- 1. Certificate Pinning v Certificate Transparency
- 2. iOS Trust Store Usually, we delegate setting up and maintaining TLS sessions to iOS. iOS checks for us if the certificate which server uses is trustworthy or not, by checking the root certificate during SSL handsha And it works well, for example if I try to intercept traffic from your device with a proxy tool, I won’t be able to do it, because this proxy tool generates certificate which is not it iOS trust store.
- 3. iOS Trust Store This method has a weakness, however: An attacker can generate a self-signed certificate and include it in the iOS Trust Store or hack a root CA certificate. Or user can install certificate to trust by m Or for example I’m as developer would want to read api calls and change request or respond from server.
- 4. Certificate Transparency Certificate Transparency is a standard for monitoring and auditing certificates. Its purpose is to help protect against fraudulently issued certificates. Certificate Transparency involves submitting a server’s public cert to a log that is available to the public. Certificate transparency works by having a network of publicly accessible log servers that provide cryptographic evidence when a certificate authority issues new certificate for any domain. These log servers can then be monitored to look out for suspicious certificates as well as audited to prove the logs are working as expected. The most critical part of certificate transparency is to be alerted to the issuance of new certificates so you can spot mis-issuance promptly. One tool for such monitoring is the open source ct_advisor hosted at https://ctadvisor.lolware.net. Another option is Facebook’s Certificate Transparency Monitoring tool which additionally can help you spot certificates created on domains trying to spoof yours. There are also tools such as Comodo’s Certificate Search tool that make it easy to search for your certificates in the public log files to help verify your expectations.
- 5. Certificate Transparency So, here's a quick overview on how it works. First, the certificate authority not only issues a certificate to the server, but it also sends it over to the log. The log then sends a signed proof that the certificate has been included, and the server hands both that and the original certificate over to the application. That means you can validate the pair together. Client (ios app) will check that server certificates are supported by valid, signed Certificate transparency timestamps from at least two Certificate transparency logs trusted by Apple. So application won’t establish connection with a server if certificate doesn’t have an evidence that it was added to a log So, certificate transparency makes it more difficult to launch attacks. If the attacker can get a certificate from an authority that's not participating in public logs, they have no way to get that cryptographic proof that the certificate has been included in the log.
- 6. Certificate Transparency Client checks for proof that certificate has been logged • In the certificate itself • In a TLS extension • Delivered via OCSP stapling
- 7. Certificate Transparency In a SSL handshake Second one check during SSL handshake. Every time a client connects to that server it sees the certificate and it wants to know whether it's still valid. So, it asks the certificate authority right there in the middle of the SSL handshake, and the certificate authority answers if the certificate still valid or not. This has some issues. One of them is that it's slow. You're right in the middle of this handshake; you're trying to get your resources, you don't want to wait to make your network connection to some other entity, especially if that server is gone down. The other major issue is that it leaks a little bit about whatever activity you're doing online. Your certificate authority gets to see which host names you're connecting to because you're sending a response up each time you connect.
- 8. Certificate Transparency OCSP Stapling OCSP stapling resolves a lot of these concerns. So, here's basically how it works. Instead of the client asking, the server asks the certificate authority, and the certificate authority hands a signed response back to the server. Then the server gives both the certificate and a promise that it's valid over to the client, all in line, all in the same handshake.
- 9. Certificate Transparency iOS app configuration Read apple documentation for more details on how to use it in iOS. It could be enabled in iOS in plist file with NSRequiresCertificateTransparency flag.
- 10. Certificate Transparency Conclusion Certificate transparency helps build secure mobile apps by ensuring a client accepts only publicly logged certificates. However, it does nothing to protect against rogue certificates that were publicly logged.
- 11. SSL pinning We use SSL pinning to ensure that the app communicates only with the designated server itself. One of the prerequisites for SSL pinning is saving the target's server SSL certificate within the app bundle. The saved certificate is used when defining the pinned certificate(s) upon session configuration. There is an additional step that can be performed that is called SSL pinning. With SSL pinning, the app can take matters into its own hands to perform additional validation on who it’s talking to, rather than relying on the more general list of trusted CAs. This would ensure that in cases like a CA being hacked, there would be an additional layer of security by the app to validate it’s still actually talking to our servers. SSL Pinning, is the process of associating a host with its certificate or public key. Once you know a host’s certificate or public key, you pin it to that host. In other words, you configure the app to reject all but one or a few predefined certificates or public keys. Whenever the app connects to a server, it compares the server certificate with the pinned certificate(s) or public key(s). If and only if they match, the app trusts the server and establishes the connection. Your mobile app should include the digital certificate or the public key within your app’s bundle. So even if someone issued certificate in trusted authority for your domain, and this certificate was added to a public log, we won’t let the connection to be established because this certificate won’t be the same as in our application.
- 12. Certificate or Public key pinning Certificate The certificate is easiest to pin. You can fetch the certificate out of band for the website. When the certificate expires, you would update your application with new certificate. At runtime, you retrieve the website or server's certificate in the callback. Within the callback, you compare the retrieved certificate with the certificate embedded within the program. If the comparison fails, then fail the method or function. There is a downside to pinning a certificate. If the site rotates its certificate on a regular basis, then your application would need to be updated regularly. For example, Google rotates its certificates, so you will need to update your application about once a month (if it depended on Google services). Even though Google rotates its certificates, the underlying public keys (within the certificate) remain static. Public Key Public key pinning is more flexible but a little trickier due to the extra steps necessary to extract the public key from a certificate. As with a certificate, the program checks the extracted public key with its embedded copy of the public key. There are two downsides two public key pinning. First, it’s harder to work with keys (versus certificates) since you usually must extract the key from the certificate. Second, the key is static and may violate key rotation policies.
- 13. Conclusion • Enable Certificate transparency in the app • Enable Public key pinning as an extra precaution I would say that the easiest step to make is to enable Certificate transparency in the application, as most of trusted Certificates authorities work with public logs already, and it will save our API from
Editor's Notes
- Usually, we delegate setting up and maintaining TLS sessions to iOS. iOS checks for us if the certificate which server uses is trustworthy or not, by checking the root certificate during SSL handshake. This certificate should be issued by trustworthy Certificate Authority organisation, who are responsible for issuing SSL certificates. This means that when the app tries to establish a connection, it doesn’t determine which certificates to trust and which not to. The app relies entirely on the certificates that the iOS Trust Store provides. And it works well, for example if I try to intercept traffic from your device with a proxy tool, I won’t be able to do it, because this proxy tool generates certificate which is not it iOS trust store.
- This method has a weakness, however: An attacker can generate a self-signed certificate and include it in the iOS Trust Store or hack a root CA certificate. Or user can install certificate to trust by mistake. This allows such an attacker to set up a man-in-the-middle attack and capture the transmitted data moving to and from your app. Or for example I’m as developer would want to read api calls and change request or respond from server.
- Certificate Transparency is a standard for monitoring and auditing certificates. Its purpose is to help protect against fraudulently issued certificates. Certificate Transparency involves submitting a server’s public cert to a log that is available to the public. Certificate transparency works by having a network of publicly accessible log servers that provide cryptographic evidence when a certificate authority issues new certificate for any domain. These log servers can then be monitored to look out for suspicious certificates as well as audited to prove the logs are working as expected. The most critical part of certificate transparency is to be alerted to the issuance of new certificates so you can spot mis-issuance promptly. One tool for such monitoring is the open source ct_advisor. Another option is Facebook’s Certificate Transparency Monitoring tool which additionally can help you spot certificates created on domains trying to spoof yours. There are also tools such as Certificate Search tool that make it easy to search for your certificates in the public log files to help verify your expectations. Every certificate should be added into public logs, so anybody could check if there are new certificates were issued for a domain.
- So, here's a quick overview on how it works. First, the certificate authority not only issues a certificate to the server, but it also sends it over to the log. The log then sends a signed proof that the certificate has been included, and the server hands both that and the original certificate over to the application. That means you can validate the pair together. Client (ios app) will check that server certificates are supported by valid, signed Certificate transparency timestamps from at least two Certificate transparency logs trusted by Apple. So application won’t establish connection with a server if certificate doesn’t have an evidence that it was added to a log So, certificate transparency makes it more difficult to launch attacks. If the attacker can get a certificate from an authority that's not participating in public logs, they have no way to get that cryptographic proof that the certificate has been included in the log. So, they hand over the certificate alone and the client can reject it. Alternatively, if they are using a certificate authority that's participating, then that tainted certificate gets logged and is publically visible, and that gives you an opportunity to revoke the certificate at the certificate authority level.
- There are 3 ways for client to check that certificate was added to public logs. Proof can be embedded in the certificate itself, or it can get handed over in the SSL handshake, or it can be delivered by OCSP stapling. First one is server sends information that certificate has been logged in the certificate it self. It’s not very secure because it doesn’t check is certificate was revoked.
- Second one check during SSL handshake. Every time a client connects to that server it sees the certificate and it wants to know whether it's still valid. So, it asks the certificate authority right there in the middle of the SSL handshake, and the certificate authority answers if the certificate still valid or not. This has some issues. One of them is that it's slow. You're right in the middle of this handshake; you're trying to get your resources, you don't want to wait to make your network connection to some other entity, especially if that server is gone down. The other major issue is that it leaks a little bit about whatever activity you're doing online. Your certificate authority gets to see which host names you're connecting to because you're sending a response up each time you connect.
- OCSP stapling resolves a lot of these concerns. So, here's basically how it works. Instead of the client asking, the server asks the certificate authority, and the certificate authority hands a signed response back to the server. Then the server gives both the certificate and a promise that it's valid over to the client, all in line, all in the same handshake.
- It could be enabled in iOS in plist file with NSRequiresCertificateTransparency flag.
- Certificate transparency helps build secure mobile apps by ensuring a client accepts only publicly logged certificates. However, it does nothing to protect against rogue certificates that were publicly logged.
- There is an additional step that can be performed that is called SSL pinning. With SSL pinning, the app can take matters into its own hands to perform additional validation on who it’s talking to, rather than relying on the more general list of trusted CAs. This would ensure that in cases like a CA being hacked, there would be an additional layer of security by the app to validate it’s still actually talking to our servers. SSL Pinning, is the process of associating a host with its certificate or public key. Once you know a host’s certificate or public key, you pin it to that host. In other words, you configure the app to reject all but one or a few predefined certificates or public keys. Whenever the app connects to a server, it compares the server certificate with the pinned certificate(s) or public key(s). If and only if they match, the app trusts the server and establishes the connection. Your mobile app should include the digital certificate or the public key within your app’s bundle. So even if someone issued certificate in trusted authority for your domain, and this certificate was added to a public log, we won’t let the connection to be established because this certificate won’t be the same as in our application.
- Certificate The certificate is easiest to pin. You can fetch the certificate out of band for the website. When the certificate expires, you would need to update your application. At runtime, you retrieve the website or server's certificate in the callback. Within the callback, you compare the retrieved certificate with the certificate embedded within the program. If the comparison fails, then SSL handshake fails. There is a downside to pinning a certificate. You will need to update your application every time you issue new certificate. Otherwise your application won’t work ones old one expires. Public Key Public key pinning is more flexible but a little trickier due to the extra steps necessary to extract the public key from a certificate. As with a certificate, the program checks the extracted public key with its embedded copy of the public key. There are two downsides two public key pinning. First, it’s harder to work with keys (versus certificates) since you usually must extract the key from the certificate. Second, the key is static and may violate key rotation policies. And, of course, nothing is 100% secure. There is a way to break through this checks too. The hacker can reverse-engineere application and update public key or just to change the result of certificate check function from no to yes. And there are ways to protect ourselves from this too but it is not a topic of todays discussion.
- I would say that the easiest step to make is to enable Certificate transparency in the application, as most of trusted Certificates authorities work with public logs already, and it will save our API from being exposed, and users from man in the middle attacks. Also we can Implement Public kay pinning as an extra precaution, so to me sure that no one tries to create a certificate for our domain in trusted Certificate Authority.