Charles Proxy website comments that:
Note that some apps implement SSL certificate pinning which means they specifically validate the root certificate. Because the app is itself verifying the root certificate it will not accept Charles's certificate and will fail the connection. If you have successfully installed the Charles root SSL certificate and can browse SSL websites using SSL Proxying in Safari, but an app fails, then SSL Pinning is probably the issue.
Just to be certain, is it possible to use an HTTP monitor like Charles Proxy (or another monitor) even though a mobile app uses SSL certificate pinning?
As Steffen said you might need to patch the app to disable certificate pinning.
Most mobile apps don't use it though :) Thus you just need to enable SSL
connections with self-signed certificate. To allow that with Android
application do following. First Download apktool. Then unpack APK file
(according to apktool 2.4.1):
java -jar apktool.jar d app.apk
Modify AndroidManifest.xml by adding this attribute to application element:
android:networkSecurityConfig="#xml/network_security_config"
Create file res/xml/network_security_config.xml with following content:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config>
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>
Generate keys to sign APK:
keytool -genkey -alias keys -keystore keys -keyalg DSA
Build patched APK:
java -jar apktool.jar b app -o app_patched.apk --use-aapt2
Sign APK file:
jarsigner -verbose -keystore keys app_patched.apk keys
If necessary convert APK to JAR for further analysis: d2j-dex2jar.sh app.apk.
More information: Network security configuration.
Certificate pinning means that the application explicitly wants to get the original certificate. If you do have the original certificate and the associated private key (which usually means that the you control the server the application is using) then it is possible to be a man in the middle (i.e. HTTP monitor) even for applications using certificate pinning.
Of course your HTTP monitoring application must support specifying a fixed certificate. It looks to me like Charles Proxy does not support this. But mitmproxy supports providing a fixed certificate for specific domains.
If you don't have access to the expected certificate and the matching key then you cannot give the expected certificate to the application. The only hope is then to somehow disable the pinning in the application itself by somehow hacking the code. Use your favorite search engine and search for "bypass pinning android" or similar to get a variety of non-trivial ways how one can try to make the application believe that it got the expected certificate.
Related
I'm currently trying to setup GlusterFS integration for a Kubernetes cluster. Volume provisioning is done with Heketi.
GlusterFS-cluster has a pool of 3 VMs
1st node has Heketi server and client configured. Heketi API is secured with a self-signed certificate OpenSSL and can be accessed.
e.g. curl https://heketinodeip:8080/hello -k
returns the expected response.
StorageClass definition sets the "resturl" to Heketi API https://heketinodeip:8080
When storageclass was created successfully and I try to create a PVC, this fails:
"x509: certificate signed by unknown authority"
This is expected, as ususally one has to allow this insecure HTTPS-connection or explicitly import the issuer CA (e.g. a file simply containing the pem-String)
But: How is this done for Kubernetes? How do I allow this insecure connection to Heketi from Kubernetes, allowing insecure self-signed cert HTTPS or where/how do I import a CA?
It is not an DNS/IP problem, this was resolved with correct subjectAltName settings.
(seems that everybody is using Heketi, and it seems to be still a standard usecase for GlusterFS integration, but always without SSL, if connected to Kubernetes)
Thank you!
To skip verification of server cert, caller just need specify InsecureSkipVerify: true. Refer this github issue for more information (https://github.com/heketi/heketi/issues/1467)
In this page, they have specified a way to use self signed certificate. Not explained thoroughly but still can be useful (https://github.com/gluster/gluster-kubernetes/blob/master/docs/design/tls-security.md#self-signed-keys).
If I have a docker application (J2EE web applications) meeting the following conditions:
there are multiple containers to be deployed (from the same image) on separate hosts which will then communicate with each other over SSL/TLS - so the containers would need their own SSL certificates, and need to trust the certificates of the other containers
these containers will additionally make HTTPS calls to other external URLs - so the certificates of these servers also need to be trusted. These external URL are not known at deployment time, so the certificates need to be imported separately
the application being a J2EE web application uses java keystore and truststore for the certificates
Given this, how should the certificates be made available to the servers?
Update: 2018-02
Docker Swarm allows secrets keeping.
https://docs.docker.com/engine/swarm/secrets/
This is however not supported in non Swarm deployments. One hacky way to get around this is to deploy to only 1 node as a Swarm.
Previous answer:
Docker doesn't currently have a way to handle secrets (it's on their road map). There's a long running thread over at Docker. It lists many ways that people use to import secrets into containers.
https://github.com/docker/docker/issues/13490
Some people use HashiCorp's Vault, others encrypt secrets on the host (env vars) or in a docker volume (that's what my team does). Containers can decrypt them when they are started (ENTRYPOINT/COMMAND). To add secrets at run time, you can create a custom container that does just that (accepts a http request and store it in a truststore). Just a suggestion amongst many that you'll see in the link above.
Application should handle this internally:
If you have a java app running inside a docker container you can use the java keystore (just then add the other containers pem's to the applications keystore in the Dockerfile)
# import my domaincert
COPY homelinux.org.pem /tmp/homelinux.org.pem
RUN /usr/bin/keytool -import -alias homelinux.org -keystore ${JAVA_HOME}/jre/lib/security/cacerts -trustcacerts -file /tmp/homelinux.org.pem -storepass changeit -noprompt
I have ~15 containers on *.homelinux.org via dyndns and a
*.homelinux.org self-signed domain certificate (dnsname=*.homelinux.org) so the containers can use ssl between them fine.
I have an issue after I installed the SSL Certificate in WorldClient, MDaemon 12.
I followed the link in installing the SSL, SSL installation was fine. Then, I followed the link to use the SSL in WorldClient. I use 888 for TCP port and 443 for https port.
When I call the webmail (http://mail.mydomain.com.sg:888) in browser, it opens properly. But, if https://mail.mydomain.com.sg:888, Secure Connection Failed error message is shown.
Any Ideas, please? Thanks.
I have solved this problem.
If you read all instruction from the link you given in your post carefully until finished, you'll get the answer.
Note: MDaemon will only display certificates that have private keys
using the Personal Information Exchange format (PKCS #12). If your
imported certificate does not appear in the list then you may need to
import a *.PEM file, which contains both a certificate key and private
key. Importing this file using the same process outlined above will
convert it to the PKCS #12 format.
You should make a PKCS#12 file from generating the (certificate) .csr and private key (.key) you have. If you on windows, install the openssl first on your PC. After successful generate the PKCS#12 file, follow the instruction again to install the SSL certification on MDaemon.
If you success, you'll see the certificate appear in the MDaemon.
Remember to restart your server or webserver to apply the changes.
Regards
I've got web application that uses authentification via LDAP. It works flawlessly, but production version is required to use SSL. We have a server running at "ldaps://ourserver.com:636", but Spring Security throws following exception when I try to connect to it:
Root exception is javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested targe
Apache Directory Studio also warns me about unknown certificate, but allows to ignore the check it and eventually to connect and read the data required.
There are plenty of questions and answers here about how to implement LDAP over SSL, but no one of them provide full solution. I've got two opportunities: to make the certificate trusted or to disable certificate check at all. No matter which way I choose, I can't figure out how to use the mechanism with Spring Security:
If I choose to use keytool and make the certificate trusted, I can't figure out how JVM / Tomcat / Spring Security will figure out which password I have defined (-keypass changeit).
If I choose to disable the certificate validation, I can't figure out what is the place the code should be placed.
I'm also curious on how Apache Directory Studio is able to make the certificate trusted for itself without that keytool import - which significantly reduces application portability? Solution like that would be perfect for my webapp, but I haven't found anything like that all.
Here is a solution I was able to use. The key thing I had to understand is that neither JVM, nor container with webapp needs to know alias and password. It's JVM headache to check all the certs registered, and this has nothing to do with your webapp. Unfortunately, the solution implies that you install the certificate for the whole JVM. That makes webapp less portable, but at least it works correctly. I've decided to provide following bash script with the webapp sources so other developers can install the cert easily on their machines:
SERVER="mydomain:636"
CRT_NAME="mydomain.crt"
CRT_ALIAS="mydomain_cert"
echo -n | openssl s_client -connect $SERVER | sed -ne '/-BEGIN
CERTIFICATE-/,/-END CERTIFICATE-/p' > $CRT_NAME
$JAVA_HOME/bin/keytool -import -alias $CRT_ALIAS -keystore $JAVA_HOME/lib/security/cacerts -file $CRT_NAME -storepass changeit
You may wish to add additional error checks, I've omitted them to simplify the script. You will need root priviledges to launch the second command.
I'm making an cfhttp to connect to an encrypted page. Seems to work fine for some sites.
I/O Exception: Name in certificate `pro.test.com' does not match host name `go.test.com'
Is there a workaround to trust this certificate even if the host name doesn't match?
Think this is more Java question, and workaround should be affecting the JRE.
Not sure if this will work in your case, but possible solution is to import this certificate into the JRE keystore.
Generic description can be found at Sun website. Though process is pretty simple.
First you should navigate the needed HTTPS URL with your browser and export the cert using SSL properties (don't remember how it is done in IE, but in Firefox something like Security > View cert > Details > Save as -- still not sure because using non-English licalization), any X.509 type should work.
Next you should import it using keytool. Navigate to the current CF JRE's bin, execute the following command (replace arguments with your values) and restart CF:
keytool -keystore <path to keystore> -import -file <path to certificate> -alias <alias>
BTW, there is a UI tool for this, but I haven't used it so can't say if it works fine.
The sites that are probably working have a valid SSL Certificate from a trusted authority.
If you have control of pro.test.com, the preferred answer would be to get a valid cert for pro.test.com installed. But if that is not possible for some reason, I see two other options:
1) Do a try/catch where you try to connect via https, and fall back on http in the event of an SSL error. Obviously this would eliminate encryption for the failed connection.
or
2) Use Sergii's solution to import the key for that site into the Java keystore.
If go.test.com is just a development server, in that case you can create a self-signed certificate and import it into Java keystore. That way you can save up on cost by not paying to CA and get a quicker turnaround to resolve the issue