銷售: 1-800-867-1380

 none
Does the Service Bus for Azure require DNS, is DNSSec/IPSec supported? Can an IP be used instead

    問題

  • There are known benefits to using DNSSec with DNS and I want to ensure I don't have a MITM issue when I use the servicebus.  How can I ensure the DNSName of the service bus instance I'm connecting to is valid?

    •  Does the serviceBus support DNSSec signed zones?  
    • If yes, DNSSec is supported, does it use NSEC or NSEC3?
    • Is IPSec supported for integrity of name resolution?
    2012年3月6日 下午 04:12

解答

  • When you delete and recreate the ServiceBus namespace the IP address will change. It can also change when there's a server side maintenance, for example, hardware failure, and things has to be moved around. There's no insurance for ServiceBus like that for a web role deployment that the IP address won't change during its lifetime.

    -Emma


    2012年3月20日 上午 09:11

所有回覆

  • Service Bus is using the same DNS service as the rest of the Windows Azure services. I don't know what security protocol layers we support there.

    That said, resolving names via secure DNS does, in the end, merely give you an IP address for the client. If someone were to sit on your route and you'd run unprotected traffic that still wouldn't help you in any way. I'll go as far as to say: For the Service Bus scenario, DNSSec wouldn't and doesn't add any actual security. The defense we have in place for MITM scenarios is TLS/SSL with a trusted certs chain which we enforce on all paths except one-way and http client send scenarios where the matching service explicitly lowers the shields. If someone were to forge a DNS reply to you, they would also have to be in possession of a valid TLS/SSL cert for your Service Bus namespace that you trust via your cert store. Since exactly that model also happens to be the trust foundation for DNSSec, getting compromised in the cert store would break both mechanisms and, thus, DNSSec does not add any further protection.

    However, if relying on chaining via the trust store is not sufficient for you and you wanted to ensure even better that you're talking to us, you can narrow it down by using HTTPS directly against Service Bus, which will enable you to first grab the cert from the root of your namespace at design time and, later at runtime, do a hard verification against the HTTPS server certificate while talking to us via HTTPS. 

    Best Regards
    Clemens

    • 已提議為解答 clemensv 2012年3月6日 下午 05:38
    • 已取消提議為解答 ChrisLaMont 2012年3月6日 下午 06:09
    2012年3月6日 下午 05:17
  • Yes,  if any of the Root CAs are hacked as described here then it's possible for DNSSec to be broken, and that has been done in the past (i.e. DigiNotor) and it's possible for me to reduce my exposure by removing unused certs, or use a solution like Convergence.io  (more info)

    I see your reasoning on doing the "hard verification" of HTTPS as a short term solution to a long term problem.

    •  Do you mean that one should verify the thumbprint of a certificate, or hash of the public key among other aspects?

    Suppose there is an undocumented protocol issue in the Service Bus, and an attacker could MITM (or similar) the process, then any inline vulnerability could be exploited (in theory).  My goal is to reduce risk in a still-new protocol (namely the ServiceBus) and prevent such a thing.

    • Would you agree that including DNSSec + IPSec in the DNS resolution process constrain WCF-based protocol security issues like this?
    • Is this worthwhile from your perspective? 

    You mention that "shields are lowered" for one-way and HTTP... but what about a HTTPS endpoint that a browser or a JSON client connects to?  I believe these are "one way" and are most likely to be affected by a DNS hijack.

    • Is it possible for the ServiceBus certificates to be "Certificate Pinned" ?
    • Lastly (most importantly) do you have threat models on the modes the Service Bus may be run in?  

    Big picture idea; if we were to limit the quantity of CA's we trust, (only use as few as needed for DNSSec) we could store certificates in DNS? Thereby reducing the risk even further, without a loss of functionality (as I started this post by saying I can just delete root-CAs) 

    We're in a chicken and egg situation... where certificates won't go into DNS until DNSSec is deployed, and people don't deploy DNSSec because there isn't a viable need.  Now that the US Government has mandated the deployment of DNSSec for their applications, I'll be surprised if you don't get other Premier/etc partners pushing for this as well. 

    I know this is a TL;DR post to many, and simply hope that the questions with a bullet are addressed.


    Thanks for your time! (and I follow your Blog postings often)


    2012年3月6日 下午 07:27
  • For those who are interested: The RFC proposal DANE for TLS allows publishing SSL keys into DNS... thereby removing the need for the CA trust and all the issues mentioned above.

    In order for this new/better security model to be used, DNSSec must be implemented over IPSec, TSIG or SIG.

    2012年3月6日 下午 07:46
  • NO, currently Azure DNS resolvers DO NOT support DNSSEC.
    2012年3月8日 上午 05:21
  • @Emma Em - This is not a question about the resolver that Azure itself uses to look up other hosts.  This is a question about the external client (at my datacenter) connecting to something in the Azure datacenter.  In this case it is the ServiceBus.  

    I assume since I own DNS for Azure Web/Computer it *might* be possible to use DNSSec when binding to that name.   The only issue is if I use a CNAME (no DNSSEC) vs an hard coded IP (which only changes when I redeploy)

    When does the ServiceBus IP change?

    2012年3月8日 下午 03:59
  • When you delete and recreate the ServiceBus namespace the IP address will change. It can also change when there's a server side maintenance, for example, hardware failure, and things has to be moved around. There's no insurance for ServiceBus like that for a web role deployment that the IP address won't change during its lifetime.

    -Emma


    2012年3月20日 上午 09:11