Author Topic: Beta  (Read 56651 times)

0 Members and 1 Guest are viewing this topic.

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #15 on: January 07, 2013, 01:46:38 PM »
Thank you for your answers, tumic.

Still one little question remains, the situation with self signed certs:

Mail.app immediately failed to connect to a private mail server using a self signed cert, already on the Keychain, once I changed it back to use SSL (this was working on the previous version of Avast!).
« Last Edit: January 07, 2013, 01:50:31 PM by specimen9999 »

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Beta
« Reply #16 on: January 07, 2013, 02:44:21 PM »
Thank you for your answers, tumic.

Still one little question remains, the situation with self signed certs:

Mail.app immediately failed to connect to a private mail server using a self signed cert, already on the Keychain, once I changed it back to use SSL (this was working on the previous version of Avast!).

This is a bug, thanks for reporting. Connections with self signed certificates were dropped, instead of resigning with the "avast! untrusted CA" certificate. The issue was fixed in build 37968 which is available now under the download link. Please try the new beta and see if it works.

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #17 on: January 07, 2013, 04:51:24 PM »
Thank you for your answers, tumic.

Still one little question remains, the situation with self signed certs:

Mail.app immediately failed to connect to a private mail server using a self signed cert, already on the Keychain, once I changed it back to use SSL (this was working on the previous version of Avast!).

This is a bug, thanks for reporting. Connections with self signed certificates were dropped, instead of resigning with the "avast! untrusted CA" certificate. The issue was fixed in build 37968 which is available now under the download link. Please try the new beta and see if it works.

Ok, testing it now.
Mail.app now asked if I wanted to trust this certificate, "avast! untrusted CA", for connecting to this server, I checked "always trust..." and now it works.
One concern thou, this means that ANY self-signed certificate will be accepted for connecting to this particular server? Since I trusted the ""avast! untrusted CA" any untrusted certificate can now be used and not only the certificate I had downloaded to my keychain?

Can't avast sign with the trusted CA if the self-signed certificate is present on the keychain?

I'm wondering about the possibility of a middle man attack going unnoticed if any self-signed certificate is used by the attacker and not the specific one I downloaded from my private mail server.

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #18 on: January 07, 2013, 05:50:56 PM »
I have one idea, maybe this is what avast! is already doing but here it goes:

When signing with the avast untrusted CA, generate a new cert for each singular self-signed cert for each specific domain, this way, when connecting to a specific domain that has had its cert changed the user will be prompt again for trusting/untrusting the new avast untrusted CA generated cert.

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #19 on: January 08, 2013, 06:28:01 PM »
Another problem, this, the SSL scanning, apparently does not work well with virtual machines running under OS X.
Probably means the same certificate has to be installed in the Guest OS (Windows in this case).

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Beta
« Reply #20 on: January 08, 2013, 06:40:06 PM »
Mail.app now asked if I wanted to trust this certificate, "avast! untrusted CA", for connecting to this server, I checked "always trust..." and now it works.
One concern thou, this means that ANY self-signed certificate will be accepted for connecting to this particular server? Since I trusted the ""avast! untrusted CA" any untrusted certificate can now be used and not only the certificate I had downloaded to my keychain?

Can't avast sign with the trusted CA if the self-signed certificate is present on the keychain?

If you have the certificate in your keychain (either "System Roots" or "System"), than the connection should be resigned with the "avast! trusted CA" certificate that is also in the keychain. so there is something wrong...

I'm wondering about the possibility of a middle man attack going unnoticed if any self-signed certificate is used by the attacker and not the specific one I downloaded from my private mail server.

All the clients I have tested (Safari, Mail, Firefox, Google Chrome) save security exceptions for the concrete host certificate, not the CA certificate that has signed it. And I'm pretty sure that any sane client does it the same way.  This means that if you add an exception for host xxx (signed by the avast! untrusted CA), the client will not accept host yyy (also signed with the untrusted CA).
« Last Edit: January 08, 2013, 06:49:11 PM by tumic »

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Beta
« Reply #21 on: January 08, 2013, 06:43:01 PM »
Another problem, this, the SSL scanning, apparently does not work well with virtual machines running under OS X.
Probably means the same certificate has to be installed in the Guest OS (Windows in this case).

Exactly. The applications in the guest OS must also trust the "avast! trusted CA".

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #22 on: January 08, 2013, 06:44:29 PM »
Mail.app now asked if I wanted to trust this certificate, "avast! untrusted CA", for connecting to this server, I checked "always trust..." and now it works.
One concern thou, this means that ANY self-signed certificate will be accepted for connecting to this particular server? Since I trusted the ""avast! untrusted CA" any untrusted certificate can now be used and not only the certificate I had downloaded to my keychain?

Can't avast sign with the trusted CA if the self-signed certificate is present on the keychain?

If you have the certificate in your keychain (either "System Roots" or "System"), than the connection should be resigned with the "avast! trusted CA" certificate that is also in the keychain. so there is something wrong...

I'm wondering about the possibility of a middle man attack going unnoticed if any self-signed certificate is used by the attacker and not the specific one I downloaded from my private mail server.
But I do have the self-signed cert in my keychain, which was working in the non-beta version of avast!.

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #23 on: January 08, 2013, 06:50:14 PM »
Another problem, this, the SSL scanning, apparently does not work well with virtual machines running under OS X.
Probably means the same certificate has to be installed in the Guest OS (Windows in this case).

Exactly. The applications in the guest OS must also trust the "avast! trusted CA".
This is not working well at all, I exported the cert from my keychain and installed it as a CA and Microsoft Update fails and a bunch of other apps.

I would love if there was a way not to scan the connections that go into Virtual Machines.
« Last Edit: January 08, 2013, 06:55:35 PM by specimen9999 »

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Beta
« Reply #24 on: January 08, 2013, 06:59:09 PM »
This is not working well at all, I exported the cert from my keychain and installed it as a CA and Microsoft Update fails and a bunch of other apps.
I would love if there was a way not to scan the connections that go into Virtual Machines.

Those apps most probably belong to the same category as Dropbox - they come with hard-coded certificates (do not use the system keychain).

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #25 on: January 08, 2013, 07:03:21 PM »
This is not working well at all, I exported the cert from my keychain and installed it as a CA and Microsoft Update fails and a bunch of other apps.
I would love if there was a way not to scan the connections that go into Virtual Machines.

Those apps most probably belong to the same category as Dropbox - they come with hard-coded certificates (do not use the system keychain).

We are talking about Windows here now (the Guest OS), it would be much much more simpler if there was a way to disable scanning SSL connections for Virtual Machines.
« Last Edit: January 11, 2013, 03:54:02 PM by specimen9999 »

Offline tumic

  • Moderator
  • Advanced Poster
  • *
  • Posts: 724
Re: Beta
« Reply #26 on: January 08, 2013, 07:14:58 PM »
We are talking about Windows here now (the Guest OS), it would be much much more simpler if there was a way to disable scanning SSL connections for Virtual Machines.

I'm also talking about Windows. It is likely, that Windows Update does not use the Windows's system certificate storage for security reasons.

Process based exceptions would be a nice feature, but they will sure not be implemented in the near future as the network shield architecture is network layer based (the shield can be used for example on a router/gateway) so there is no info about the process available.

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #27 on: January 08, 2013, 07:31:08 PM »
We are talking about Windows here now (the Guest OS), it would be much much more simpler if there was a way to disable scanning SSL connections for Virtual Machines.

I'm also talking about Windows. It is likely, that Windows Update does not use the Windows's system certificate storage for security reasons.

Process based exceptions would be a nice feature, but they will sure not be implemented in the near future as the network shield architecture is network layer based (the shield can be used for example on a router/gateway) so there is no info about the process available.

What about having a set or sets of pre-defined domain scan exclusions?

Offline specimen9999

  • Sr. Member
  • ****
  • Posts: 350
Re: Beta
« Reply #28 on: January 09, 2013, 06:55:09 PM »
Mail.app now asked if I wanted to trust this certificate, "avast! untrusted CA", for connecting to this server, I checked "always trust..." and now it works.
One concern thou, this means that ANY self-signed certificate will be accepted for connecting to this particular server? Since I trusted the ""avast! untrusted CA" any untrusted certificate can now be used and not only the certificate I had downloaded to my keychain?

Can't avast sign with the trusted CA if the self-signed certificate is present on the keychain?

If you have the certificate in your keychain (either "System Roots" or "System"), than the connection should be resigned with the "avast! trusted CA" certificate that is also in the keychain. so there is something wrong...

I'm wondering about the possibility of a middle man attack going unnoticed if any self-signed certificate is used by the attacker and not the specific one I downloaded from my private mail server.
But I do have the self-signed cert in my keychain, which was working in the non-beta version of avast!.
As for the self-signed cert problem, I deleted the cert and started over again by getting the cert from the server into my System Keychain, rebooted, but still, Mail.app asks for trusting "avast untrusted CA signed cert". On Safari, strangely, the connection is trusted without prompting but it's signed with self-signed cert on my system keychain and neither with avast trusted or untrusted CA, and yes, I made sure there are no exceptions in vast and that it's scanning web secure connections.
So something's weird going on with self-signed certs.

Offline pnoguchi

  • Newbie
  • *
  • Posts: 5
Re: Beta
« Reply #29 on: January 10, 2013, 04:46:59 AM »
Using the newest beta (37968), I find I can install WebRep in Firefox 18, Safari 5.1.7, but not in chrome 23 which simply states that the plugin cannot be installed.

-P