OCSP proxy for firewallvm

[marmarek]

Reported by joanna on 3 Jul 2014 11:54 UTC
A typical problem: the user wants to allow only https traffic to select AppVM, yet for most https sites to work correctly (at least those with EV certs) the web browser is expected to also connect over oscp to check the cert. Unfortunately OCSP is HTTP not HTTPS...

Currently I manually look into the cert details where URI to OCSP is written, and then manually add this to the firewall rules. Sometimes I can't get the "green bar" working though...

Migrated-From: https://wiki.qubes-os.org/ticket/879

[marmarek]

Comment by marmarek on 4 Jul 2014 22:45 UTC
Some CAs have very sophisticated infrastructure for hosting OCSP, includinga whole server farm, DNS round robin changing every few minutes etc. For example I had to add those rules for verisign (manually in qubes_firewall_user_script!):

#  crl.verisign.net
iptables -I FORWARD -s X -d 199.7.0.190/255.255.0.255 -p tcp --dport 80 -j ACCEPT
#  ocsp.verisign.net
iptables -I FORWARD -s X -d 199.7.0.72/255.255.0.255 -p tcp --dport 80 -j ACCEPT
#  seal.verisign.net
iptables -I FORWARD -s X -d 199.7.0.231/255.255.0.255 -p tcp --dport 443 -j ACCEPT

But apparently it isn't working anymore.

So indeed some proxy would be helpful. Potential problem: how to let the browser use the proxy? It would be the best if it would be used only for OCSP queries, but I'm afraid it isn't possible. Perhaps it should intercept all http traffic (and filter it similar to our yum proxy)?

[marmarek]

Comment by marmarek on 4 Jul 2014 22:45 UTC
Some CAs have very sophisticated infrastructure for hosting OCSP, includinga whole server farm, DNS round robin changing every few minutes etc. For example I had to add those rules for verisign (manually in qubes_firewall_user_script!):

#  crl.verisign.net
iptables -I FORWARD -s X -d 199.7.0.190/255.255.0.255 -p tcp --dport 80 -j ACCEPT
#  ocsp.verisign.net
iptables -I FORWARD -s X -d 199.7.0.72/255.255.0.255 -p tcp --dport 80 -j ACCEPT
#  seal.verisign.net
iptables -I FORWARD -s X -d 199.7.0.231/255.255.0.255 -p tcp --dport 443 -j ACCEPT

But apparently it isn't working anymore.

So indeed some proxy would be helpful. Potential problem: how to let the browser use the proxy? It would be the best if it would be used only for OCSP queries, but I'm afraid it isn't possible. Perhaps it should intercept all http traffic (and filter it similar to our yum proxy)?

[marmarek]

Comment by axon on 22 Jul 2014 12:32 UTC
What if you just allow HTTP access to the entire CIDR block of the OCSP host in the AppVM's firewall rules?

For example, if your desired EV website is https://twitter.com, whose OCSP URI is http://EVSecure-ocsp.verisign.com, you would allow 23.0.0.0/12 over HTTP in the firewall rules of the AppVM.

This is currently working for me.

[marmarek]

Comment by axon on 22 Jul 2014 12:32 UTC
What if you just allow HTTP access to the entire CIDR block of the OCSP host in the AppVM's firewall rules?

For example, if your desired EV website is https://twitter.com, whose OCSP URI is http://EVSecure-ocsp.verisign.com, you would allow 23.0.0.0/12 over HTTP in the firewall rules of the AppVM.

This is currently working for me.

[andrewdavidwong]

What if you just allow HTTP access to the entire CIDR block of the OCSP host in the AppVM's firewall rules?

I've been using this workaround for a while now, but it's not entirely reliable, since sometimes the OCSP host IP changes. So, some kind of proxy would be much better, I think.

[andrewdavidwong]

What if you just allow HTTP access to the entire CIDR block of the OCSP host in the AppVM's firewall rules?

I've been using this workaround for a while now, but it's not entirely reliable, since sometimes the OCSP host IP changes. So, some kind of proxy would be much better, I think.