BEV_EVENT_ERROR

[janusloo]

Hi there,

I keep getting the following errors when I tried to access inbox from google:
SNI peek: [inbox.google.com] [complete], fd=47
Connecting to [216.58.212.133]:443
pxy_connected_enable: SSL connected to [-]:- TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305
CLIENT_RANDOM B4C70D68E61E74699267DBCAE725936250B55FB110259C37A46F94E4DB5FEB42 761DEA9FC5DEEA1418BEA4BD045F64DDE82B79DB711BCCFF5F8935186DB326DC1D701BD09F41DB20AEABFD6E67A0334C
===> Original server certificate:
Subject DN: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=mail.google.com
Common Names: mail.google.com/mail.google.com/inbox.google.com
Fingerprint: 47:C9:7F:F3:E6:2C:9B:CE:0E:954B:95:23:0B:BC:FA:71:EE:A4:68
Certificate cache: MISS
===> Forged server certificate:
Subject DN: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=mail.google.com
Common Names: mail.google.com/mail.google.com/inbox.google.com
Fingerprint: E4:80:3A:D7:52:98:FF:F6:48:6F08:24:B6:73:B5:77:BB:EF:E8:21
Received privsep req type 05 sz 5 on srvsock 8
Certificate cache: KEEP (SNI match or target mode)
pxy_ssl_shutdown_cb: fd=48, SSL_free() in state 00000001 = 0001 = SSLOK (SSL negotiation finished successfully)
BEV_EVENT_ERROR
Error from bufferevent: 0:- 336151574:1046:sslv3 alert certificate unknown:20:SSL routines:148:ssl3_read_bytes
pxy_bev_eventcb: SSL disconnected to [216.58.212.133]:443, fd=47
pxy_bev_eventcb: SSL disconnected from [10.8.0.2]:59632, fd=47

Inbox will not refresh the content and gave No Connection error. I also get similar error in whatsapp. Has it got something to do with my self-signed certificate? I already imported the self-signed certificate onto my Android device so that is not the cause. Not all forged certificates generated an error though.

I have sslproxy version v0.5.6-7-g859da0a so it's the latest. I noticed that web browsing on Android phone is fine with the forged certificates but when in android apps these error became more. I think I miss something here but what? Hopefully you can help me with this.

Thank you!

Eric

[sonertari]

Yes, I can confirm this issue. I can reproduce it with an Android emulator.

I have been reading about this sslv3 alert certificate unknown error since, and people say that this is due to the server requesting client authentication, but then rejecting the client certificate, perhaps because it was issued by a custom CA. So this might explain why this is happening with mobile apps more often than web browsers (for example, this happens with googleapi a lot, because I guess it asks for authentication from the client app).

Although I have tried to use the new ClientCert and ClientKey options, I couldn't stop these errors, perhaps because I have used a self-signed client certificate. Perhaps you can try yourself and report too.

Btw, there is at least one more related error perhaps: tlsv1 alert unknown ca.

So, I don't think there is a mistake in your setup. But I couldn't find a solution yet. I am still working on it. I am not sure about anything yet, but I didn't want to leave you unanswered too long.

[janusloo]

Hi, I tried using the ClientCert and ClientKey but the errors still occur.

I did some research online and came across this:
https://blog.netspi.com/four-ways-bypass-android-ssl-verification-certificate-pinning/

Perhaps this article can give you more insight to the issue.

Thank you for your time. I will be waiting for an elegant solution.

[sonertari]

My current understanding is that this issue is happening on the server side of SSLproxy.

Unfortunately, if true, this means that nothing we do on the mobile device will help (1). Btw, I wouldn't be able to do anything in the SSLproxy source code to achieve any workaround on mobile devices anyway (2), mentioned in that blog post or elsewhere.

Because of (1) and (2) above, it currently seems to me that there is nothing we can do, unless we use a client certificate with the ClientCert option, but it has to be signed using a trusted CA. Is it possible to get the certificate that the app is using on the mobile device and then use it on SSLproxy with the ClientCert option? I mean something like this. That would be a very good test of my claims.

To reiterate, this issue is happening because, for example, Google is asking for client authentication, and then quite naturally rejecting our self-signed client certificate. I hope I am wrong, but we cannot bypass this security.

[janusloo]

Is it possible to get the certificate that the app is using on the mobile device and then use it on SSLproxy with the ClientCert option? I mean something like this. That would be a very good test of my claims.

I don't have a rooted device so cannot extract the certificate from the mobile app.

[sonertari]

Just for the record:
droe/sslsplit#173
droe/sslsplit#46
droe/sslsplit#194

[janusloo]

If I understand the issues correctly, I need a new client cert and private key from my own custom CA to authenticate to sites or mobile apps that need client authentication? If so I will give it a try. Thanks.

[sonertari]

I thought you have already tried it in your #4 (comment). I think this will only work with sites which accept self-signed client certificates (signed using your own CA). With others, like googleapi, I don't think it will work. I've tried, and it doesn't.

Btw, if I were the admin of a site requesting client certificate authentication, I wouldn't accept self-signed client certificates, because it goes against the purpose of mutual authentication. In other words, google is issuing me a client certificate which a third party cannot forge, so it knows I am the person that it thinks I am.

So, as I said in #4 (comment), we need a client certificate signed by a CA trusted by the site in question, e.g. by extracting a client certificate from the mobile device.

Even if we could do that, as mentioned in a comment here, The client-side certificate must be issued per user, so I don't think we can support more than one mobile app with sslproxy/sslsplit anyway, because the ClientCert and ClientKey options accept only one cert and key pair. (It seems to me that these options in sslsplit are for temporary forensic analysis of a certain connection of a certain user.)

This article explains mutual authentication nicely too. I was hoping that I am wrong at some point, but any new article I read about this subject confirms my understanding, unfortunately.

[janusloo]

Oh I didn't use a correct client certificate and private key in Comment #4 so it didn't work. I have just tried with a self-signed client cert and key and it didn't work either. So I understand now there is no way to forge a client certificate.

btw, how does the Passthrough parameter work? I set it to yes but the SSL connection is still dropped. Is there a way to make an exception otherwise for SSL connection that requires client authentication?

[sonertari]

Yes, the only remaining option in this case is passthrough. But the mode of operation of sslproxy is so different from that of sslsplit, I never intended that sslproxy run as passthrough. In fact, I was planning to remove that feature, because it could be used to bypass the UTM inspections provided by the system (think DLP). So I had never tested it, now thanks to you, I know that it really does not work, as I expected :). Since in this case the passthrough option would be helpful, I will try to find a way to make it work, but I don't know when or if I can do it. Sorry.

[sonertari]

Btw, you can always use a pf rule to bypass sslproxy for connections going to such sites, e.g. googleapi. But note that they may have multiple IP addresses in their DNS records, e.g. like google.

[janusloo]

Thanks for the tip to bypass sslproxy but I am using Linux and do not know how to block specific traffic based on sites.

[sonertari]

Although my claims above assume that this issue is related with client certificate authentication, this article makes me doubt about something else: You said that your device is not rooted, are you sure you have really installed your own CA certificate on that device? I am reading that this is not easy, and getting harder with Android 7+ devices (perhaps even impossible with non-rooted devices). Just FYI.

[sonertari]

Since I have debug logs with DEBUG_PROXY on, I now know that this is happening on the client side! This means that the issue I can reproduce on my test system is really about installing SSLproxy CA certificate on the device, actually on the app on the device.

I bet yours is the same, because even though the logs you provide are not detailed (due to DEBUG_PROXY being disabled), the line above the error reads SSLOK (SSL negotiation finished successfully), which means that the handshake on the server side was successful, and the error has happened afterwards.

This all means that my comments about client certificate authentication has nothing to do with this issue :). If true, this is good news, almost.

But note that you may need to install your CA certificate on each application on the device (applications do not have to use the same certificate store), which may or may not be possible, as I mentioned before.

The same is true for PC applications too. For example, Firefox has it installed, so it does not complain, but Netbeans does not have it, so it complains, etc. And when Netbeans complains, I immediately see this same BEV_EVENT_ERROR error in the sslproxy logs!

In short, I think I am sure about my understanding now, at long last (sigh). To reiterate, this error is happening on the client side due to the client rejecting the CA certificate of SSLproxy. And to fix that, you need to install this CA certificate on the application(s) on your device, if you can.

[janusloo]

I have already imported the self-signed certificate on my device (user certificate store). It is not possible to install certificates on each applications without rooting my device and modifying the mobile apps.

If your finding is true, then these apps bypass the default Android certificate store and distribute their custom certificate chain in the app. According to this post these apps are targeting Android version 6.0 or higher. If this is true then there is no way for sslproxy to intercept them.

[sonertari]

Yes, your conclusion is right, we cannot do anything about this issue.

Just for the record (for other readers of these comments), the post you mention reads "If the application targets Android versions later than 6.0, however, it won’t trust the user-added CA store" as you say. I also have added the SSLproxy CA to the user CA store on my Android emulator, and it does not work as expected.

And in this case, the passthrough option would not help either, unfortunately (now I wish that this issue were actually about client certificates as my previous claim, then I could try to fix passthrough to work around it). So I guess we are done with this issue, and can close it, with failure, right?

[janusloo]

Fine with me. Thanks for your time!

[janusloo]

I think if you can properly implement the SSL passthru feature in sslproxy then it would be perfect. I tried this passthru thing in a python program and passthru for e.g. *.googleapis.com works as expected. The traffic will not be filtered but the secure connection would work. Just my suggestion and I think you should know about it. It is doable.

[janusloo]

More information about Android changes in trusted certificates authorities here.

[sonertari]

@janusloo, can you try again? I think I have fixed the passthrough option in SSLproxy. So I think it behaves similar to SSLsplit, i.e. SSLproxy enables passthrough in exactly the same conditions as SSLsplit, and I think it works.

But beware, I don't think this will solve the issues you submitted above (it doesn't solve on my test env). Because, when the client rejects the SSLproxy CA cert, the connection is already established, hence cannot be switched to passthrough mode. So, it can only be disconnected upon such an error.

Btw, I have checked the python program you mentioned. It uses a bypasslist to pass the sites in the list through (and works with the CONNECT method for proxy tunneling only?), which is a very different passthrough feature (right?). It is like shallow SSL inspection, which requires a lot of work on SSLproxy to implement. What I mean by shallow inspection can be explained by the comments here.

[janusloo]

Hi @sonertari, where can I find the new passthru codes? Develop or Master? Thanx

[sonertari]

Both now, but use develop branch, as it has autossl fixed with further improvements. But I don't think it is going to solve your issues, as we discussed above.

[janusloo]

Ok thanx I will report back. Which parameter should I use? Passthrough yes?

[janusloo]

Indeed, it still doesn't work with Passthrough yes ;-(

[sonertari]

I'm not surprised. It is not possible to engage passthrough mode after SSL connection errors out. The only solution may be shallow inspection as you suggested and I have replied in my comment above.

[janusloo]

Okay then. Thanks for trying!!