(Resending as my 1st attempt didn’t seem to make it to the list..) Hi Valery
On 09/03/2016 11:46, "Valery Smyslov" <[email protected]> wrote: >Hi Graham, > >a few comments on your text. > > A number of attacks can occur if implementations use the HASH and > URL, malicious parties can send a URL to redirect a VPN gateway to a > server which does not contain the HASH of the certificate, but > >The server never contains hash, it contains the certificate (or >CertBundle) >matching the hash. Thanks - sorry, I used the wrong terminology. Just to confirm - for the malicious case I setup my webserver www.evilgraham.com, I send you HASH + URL http://www.evilgraham.com/djfjkdfkdfkdfjfdj (hash being 'djfjkdfkdfkdfjfdj') there’s a file on my server named ‘djfjkdfkdfkdfjfdj’ (Yoav’s 4k movie..) You now download this movie.. > > instead contains a large file that is then downloaded by the VPN > gateway consuming CPU and memory. For this reason the size of file > pulled by the server SHOULD be limited to a certain value dictated by > the policy for the issuing Certificate Authority. The VPN gateway > >I'm not sure if CAs have such a policy (there is a BasicConstraints >extension >in certificates, which is relevant, but not the same). Sorry - I wasn’t clear. I was referring to security policy for the CA. So say your CA issues certs with a RSA 2048bit keypair, you would know the approx size of the certificates generated. You would know not to download a cert bigger than X bytes. As I understand some certificate can become very large (if containing images etc..), there’s no hard set limit on a certifciate size, but the ‘security policy' for the CA (what attributes are included would be known), so an informed decision could be made to the size of the certificates. > > Malicious or mis-configured clients can make numerous requests that > exhaust the HTTP or TCP daemon running on the VPN gateway. The amount > of requests that are performed in a given time should be monitored > and rate limited should HTTP connections fail. The VPN gateway > architecture should be designed so that the repository containing > certificates is on the protected interface of the VPN gateway. This > >Sorry, this is impossible (if by "protected interface" you mean >the interface protected by IPsec). That's a chicken-and-egg problem - >you need to get the certificate before the SA is established >(see Section 2 of RFC7296). I don’t mean IPsec protected interface. Think LAN and WAN. So IKE/IPsec comes into the WAN interface and then your protected networks are on your LAN. Maybe better terminology would have been Management, basically an interface that isn’t internet (or WAN) facing and not accessible by the IKE clients (so can’t be turned over). I’ll reword this, thanks for the pointer. > > >Generally speaking, I don't think the attack is so serious. >It is the IKE responder who retrieves data, so it is up to the responder >to decide how much data it retrieves. The malicious http server cannot >send >more than one TCP window bytes unless the responder sends next ACK. >And I think that the sane responder would read the first few bytes >and determine the size of the whole ASN structure (certificate or >CertBundle), >since all the structures are required to be DER-encoded. >And I agree with you that if the length is suspicious (e.g. >greater than 16 KBs, which is more than enough to hold >four certificates, the number - required to be supported by RFC7296), >then it can just abort the TCP session. But there’s also the case for someone getting the VPN gateway to connect to a malicious HTTP server, even for the 16k limit they can drip feed the file (very slow transfer). Do this a number of times and you could exhaust all TCP sockets on the VPN gateway (maybe then preventing CRLs being retried etc). >So I don's see it as an amplification attack that Yoav described - >it is not full 4K moovie unless the responder is absolutely careless. Well - for those careless responders it’s 2 packets to the get the VPN gateway to download the movie (200k+ packets etc…) Seems like a nice amplification to me. >Anyway, isn't the text better be placed in the Security Considerations >section? Sure - I can put it in there. I’ll tidy up the words to clear up the confusion. Thanks for the comments Valery. cheers > >Regards, >Valery. > > > >>Hi >> >>I¹ve updated the draft (attached). Please see section 6.2, where I >>describe a method to (potentially) pull your movie in 4k quality.. >> >>cheers >> >>On 06/03/2016 17:09, "Yoav Nir" <[email protected]> wrote: >> >>>Sending a request and directing a server to send an entire movie in 4K >>>quality using RTP in an interesting amplification attack. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
