Black Ops of Fundamental Defense:

Black Ops of Fundamental Defense:Introducing theDomain Key InfrastructureDan KaminskyChief ScientistRecursion Ventureshttp://www.recursion.com

This is my 11th year at Black HatIt’s been quite the ride!Contrary to popular belief, I haven’t always been obsessed with DNSOnce upon a time, I was obsessed with SSHMy first Black Hat talk got a feature put into it!Dynamic Forwarding / -D flagAnyone notice how excited I’ve been about DNSSEC?This talk is about why.

IntroductionI’m Dan Kaminsky, and this is my 11th Black Hat talk.I’ve not always been talking about DNSTen years ago, my talk was all about SSHSSH (Secure Shell) is the most popular package for remote system administration in the worldWe used SSH to administer remote machinesOn a security audit of SSH, it became clear that tunnels (for other protocols, like web browsers) could be opened up on demand

Thus, the –D FlagDynamic Forwarding was born-D flag“If you can SSH into the box, you can administer its web interface”Code is now in every Mac and Linux system on the planetThis was the result of a pen test!

An Unsolved ProblemOK, so now we can manage any machineHow do we log in?Cross Organizational Authentication was then, and remains now, a capital-h Hard Problem.Verizon Business: 60% of compromises traced to authenticationNo passwordsDefault passwordsShared passwordsCan we do better?

[That’s A Strange Username…]

[What’s that in authorized_keys2?!]

DNSSECFor the last eighteen years, people have been trying to secure the DNSNow it’s our turn to secure everything elseWe live in the future.I recently spent six hours in a secure facility helping sign the DNSSEC root – I’m honored to have been a part of thatEverything in this talk is only possible because the DNSSEC root is finally signed.But I get ahead of myself.

What Recursion Ventures Stands ForIt is time to get serious about defense.Our society runs on Information Technology. We can’t go back.That does not mean we stop talking about how to break into thingsThe only hope we have for creating effective defenses is maintaining strong offensive knowledge, and using it to drive defensive engineeringOtherwise, we end up with Please Turn Off Your Cellphones Before Departure Syndrome – major exertions of effort with no measureable or measured relationship with the problem at hand

The Need For Fundamental DefenseWe believe there are fundamental links between most of the security failures out thereTwo core issuesIt’s because of these two issues that attackers succeed.First: We don’t know how to write secure code affordablySecond: We can’t authenticate across organizational boundariesRecursion is working on both problemsInterpolique, a secure (and public! Go break it!) framework for cross-language communication, is dealing with some of the firstWe’re here today to talk about the second

There Are Five Audiences For This TalkThe UserThe BuyerThe BuilderThe Breaker

To The UsersDKI (Domain Key Infrastructure) will let you know, when you receive a mail from your bank, that it is actually from your bank.We have been talking about secure email for over a decadeWe apologize. We have failed you.We ask you too many questions.We make awful demands upon your memoryWe blame you when things go wrongOur failure comes not from lack of trying, but from taking the wrong approach.

To The BuyersDKI is going to increase your budget.Ten years ago, your community spent hundreds of millions of dollars trying to implement Public Key InfrastructureOn the one hand, it did not work.On the other, do you think we need strong authentication any less now, than we did a decade ago?Information Technology has only gotten more important, not less.The question is: Is this pendulum swing, with the DNSSEC root being signed, finally the one that will solve this problem?We believe so.

To The BuildersDKI will make your security products scaleHow much stuff have you sold that sits on customer shelves, because it worked in the lab but failed large scale deployment?How many devices have you really been able to ship with certificates?How many sacrifices have you had to make in your products, that in the end equated to disabling the security in the first place?Ahem, devices that don’t even validate the identity of the SSL peer they’re communicating with

To The BreakersYou are the (second) most important group here.People think code is secure until proven otherwisePeople are wrong. And you know it.“Holy crap! Recursion Ventures just made DNSSEC OpenSSH Pre-auth!”Thank you for noticing. Lets get to work.

Towards Radical TransparencyRecursion Ventures will be actively supporting an aggressive public audit of all DNSSEC and DKI technologiesJustin Ferguson (jf / @not_me) is auditing LDNS, NLnet Labs’ excellent DNSSEC libraryHis report will be released publicly in a few weeks (by September 1st, 2010, probably earlier)Initial findings are mostly positive, with some findsNlnet Labs is being very supportive of this effort

To GrandmaWelcome to your seventhBlack Hat!You are officially more l33t than 90% of this room Yes, everyone, there are cookies 

What We Are Here To Do1) Explain DNSSEC. It’s simpler than you think.2) Deploy DNSSEC. See #13) Discuss some approaches that may make DNSSEC scale better on the server side.4) Describe how we will acquire end-to-end trust via DNSSEC, thus enabling DKI5) Demonstrate DKI working. Not theoretically, but right here, right now, on stage.Code or GTFO

Some Ground Rules [0]No Religion But OneWe don’t care about Not Invented HereSome of the coolest things in this talk were not my ideaWe have an Internet to fixBigger than any one person…or one organization…or one community…or one country

Some Ground Rules [1]We can’t care about style.Skype’s Law: The Internet was frozen in 2001. Deal with it.Theoretical elegance is great, and there are times where it’s important to “take a stand”But it’s gotta work.And it’s gotta work well. Not just barely.Systems that barely work are barely deployed.1M SSL endpoints.Half of them don’t even pretend to be secure.Corollary: We can’t care about historical precedentHistorically, we have not achieved success.

Ops Is KingWe do care about OperationsWe will not win by calling people Lazy and StupidGreat for our egos – defines us as intelligent and industrious – but the customer remains 0wnedWe will not win through moralization“You’re bad people! You release broken code!”We will really not win through regulationProduct liability is the end result of no market forces differentiating secure code from badWe will win the old fashioned way: By delivering a better product to market, as judged by the people who actually have to run with it

Timelines18 months ago, we declared at Black Hat DC:DNSSEC, as an implementation, is an undeployable train wreck.It will get better.Today is Yesterday’s FutureLook what we have!

Market Survey(Not A Sales Pitch)Open Source ServersBind 9.7 (“DNSSEC for Humans”)PowerDNSSEC (Lazy Signing)OpenDNSSEC (IXFR Secure Slaves)Commercial ServersXeleranceSecure64InfobloxManaged Service ProvidersAfilias / ProteusVerisignDynUltraDNS

Why This MattersThere is a robust market of companies out to make DNSSEC easy to deploy.This is a sign of maturityA bevy of suppliers is the mark of a healthy industryA lot of skin in this gameA lot of people out to make DNSSEC operations-friendlyI’m here to show where it’s all going, on the six-to-eighteen month timeline

1) DNSSEC is not that complicated Normal DNS:Ask a question, get an answerAsk a question, get a referralAlice: Jenny’s number? Ask Travis.Travis: Jenny’s number? Ask Charlie.Charlie: Jenny’s number? 876-5309

Not Too DifferentDNSSECAsk a question, get an answer and a signatureAsk a question, get a referral and a signatureAlice: Jenny’s number? Ask Travis™Travis: Jenny’s number? Ask Charlie™Charlie: Jenny’s number? 876-5309™Is that it?Mostly

What’s NewReferrals now contain new keysBefore, you were just told where Travis was“Oh, ask Travis, he’s down by the water fountain”Now you’re told how to recognize him“He’s the guy with the dreadlocks.”Who is now the new Chief Hardware Officer of Recursion VenturesWelcome aboard, neighbor ;)Computers can make stronger identifiers than people can, so we use cryptoBut it’s just the same

Is That It?There’s magic here and thereSaying “Jenny has no number” has some magic (NSEC/NSEC3)Records can expire (time exists)Keys can lead to other keys (KSK/ZSK)Some of the magic is optionalMore than you’d thinkAll of the magic can be implemented in an easily deployable mannerEasiest of course is a managed service or a “one click” deviceBut, failing that, lets deploy DNSSEC.Right now.

A Simple Bind9 Install With A Handful Of Small Zones

First, we set the main server port to 50053

But what about .org? Don’t we need to tell the parent where we are?

Why Phreebird WorksDNSSEC was designed to allow a “key in a vault” approach to security“Offline keying” – no ability to generate responses on demandAge: DNSSEC was designed in an era where CPUs were slow and RSA acceleration was horribly expensive/nonexistentWe live in the future. Neither is true anymore.Scale: DNSSEC has to handle everything from the smallest domain to the root to .com – for very, very large sites, the resources exist to implement offline keyingWhen you ask why Verisign hasn’t signed .com yet, remember, .com is absolutely massive on a ridiculous scale

The Key ObservationOffline Keying is operationally expensive.The contortions that one must go through to support it are significant in DNSSECThe thrust of most of the products coming out is to hide it all behind cron jobs…and not just in DNSSEC

Not Just DNSSECLook at PGP / GPGBest solution available for secure emailSure there are keyservers, but everyday use is supposed to depend on keyrings with validated contentsWhat happens when you receive mail from someone not on your keyring?What happens when you have to send mail to someone not on your keyring?What happens when a key expires?What happens when a key is lost?What happens when a key is stolen?

PopupPopupPopupPopupPopupPopupPopupPopup

A simple statementCan you imagine if DNS worked that way?It doesn’t.Requests are made on demand, and are cached for relatively short periods of timeThis works very wellWhenever possible, DNSSEC should be allowed to work like DNSThat being said, it’s awesome that DNSSEC can operate in an offline capacity

Phreebird Is An Online KeysignerWe sign requests when they come in, not in some huge precomputation phaseWe didn’t invent online keysigningSSL, SSH and IPsec all have the keys onlineWARNING: There’s some religion here. The reality however is that every company has keys online for some protocols. HSMs exist to keep keys from leaking if necessary, but not everything exists within an HSM!Quiet but very visible support throughout a number of the RFCsThanks, Ben Laurie!We’re not the only implementation that’s doing itBert Hubert’s PowerDNSSEC does it as well

Phreebird Is A ProxyAs close to a “bump in the wire” as possibleNothing Operations likes more than minimal disruption There’s effectively nothing to configure – turn it on and go to lunchPresent implementation – UDP port forwarderComing (very) soon – Linux Mangle TableMangle Tables maintain original Source IP, which is actually important for many servers (GeoIP, etc)

Phreebird is fastThank you, Linux Kernel Developers and LibEvent developersNielsProvos is a badassFew hundred lines of code == DNS server that runs at 60,000 qps on stock fast hardwareSo says author of evldnsWe won’t be so fast, since we have a backend to talk to and some records to signBut we’re pretty clearly faster than almost any name server we’re put in front of 

PhreebirdcachesThe general idea is we always send a query to the backend, and sign each responseIf we’ve already signed that particular response, we go to the cache, otherwise we generate the response on the flyThis design keeps us compatible with dynamic name serversCDNs, etc.

Phreebird is openYou’d just reimplement it anyway Should have code out today, but demos took precedence over releaseSend an email to info@recursion.com if you want a pre-preview copy with known (and horrifying) bugsCode should be out in next few weeks (with pen test report)Remember, six to eighteen months – this is where things are going, not where things are at

Phreebird does a lot of things I don’t have time to tell you about todayThere is a lot of obscura in the DNSSEC realm that we’ve been filtering throughHow do we handle nonexistent records dynamically?How do we tunnel trusted records to registries when the registrars in front of them don’t implement DNSSEC?How do we manage rollover and expiration?How do we keep clocks in sync, especially given the chicken-and-egg relationship between NTP and DNSSEC?The full version of these slides will contain answers to these questions, but right now we want to demonstrate the value of this platform conclusively.

PhreebirdliesWhite lies Consider the problem of nonexistent namesDNS supports NXDOMAIN – “this domain doesn’t exist”DNSSEC supports NSEC/NSEC3 – “this range of domains doesn’t exist, and here’s proof”Authoritative NonexistenceActually really useful, surprisinglyThe reason NSEC/NSEC3 operate on ranges is because there are a finite number of records that do exist and an infinite number of records that do notOffline signers need the ability to say, “anything between here and here, here’s proof it’s not real”

White LiesIf you have an online signer, it’d be great to just say “that name you just asked for, here, let me synthesize some proof it doesn’t exist”Problem: The language only lets you express ranges that don’t exist, not actual domainsSolution: Generate a record in which there is nothing between “the name right before this one” and “the name right after this one”Simple explanation: “You looked up foo. There are no names between fon and fop”A little too simple…

NSEC White Lies Are A Little Ugly[what they look like]

Solution: NSEC3 White LiesIn NSEC3, rather than saying there are no values between “fol” and “fop”, all names are turned into very large numbersThis is so offline signers don’t leak all the names in the domainNice side effect: It makes it much easier to implement the White Lies semantic“No names between 1 and 3”Pretty easy to prove that the only name blocked is 2

Beyond the Name Server“No Man Is An Island”Neither is any zoneDomains chain, from the root to .org, and from .org to foo.orgHosting foo.org is not enough -- .org needs to know where to send people who are looking for foo.orgThis is the NS record in DNSHosting foo.org securely is not enough -- .org needs to know the key to switch people to when they’re looking for foo.orgThis is the DS record in DNS

The ProblemEvery company (“registrar”) reselling access to .org lets you declare a NS recordVery few companies reselling access to .org let you declare a DS recordDS is very newIt’s a tremendous amount of work to rev UIWe have yet to prove the value of that workI’m working on it! Here! Now!

One Solution: NSDSBefore: ns1.domain.comAfter: nsds-v1-60485-5-2-D4B7D520E7BB5F0F67674A0CCEB1E3E0614B93.nsds-C4F9E99B8383F6A1E4469DA50A.domain.comThe idea is that the DS record follows the same secure path it otherwise would, it just gets tunneled inside the NS recordFamiliar? This is the coolest part of Dan Bernstein’s DNScurveIt’s a great idea and DNSSEC should adopt it

Supporting RotationNSDS is great for the initial keyingPast that, in DNSSEC, keys can sign keysName servers should be able to publish “this is the next key I’m going to use, please see me signing the new key with the old key”Somebody should visit the server to collect the updatePossibly, Phreebird could send a NOTIFY packet somewhere – “heh, get my new key”

On TimeThere is another external dependency in DNSSECTime1) Signatures expire2) What if your clock is wrong?

ExpirationWho here has been to a site where the certificate expired?Why is there UX for this?Fundamental flaw: When a system fails enough, it gets special case handling.Prompts are the direct result of a security system that fails too often in legitimate useExpiration seems like a good ideaDon’t we want to make sure that a bad guy eventually loses access?

OPS IS KINGDo we buy hard drives by the year?Servers?Networks?Keyboards?No, because that’s totally ridiculousCertificate expiration is not the only reason why X.509 is only deployed when absolutely requiredBut the inconvenience to the ops guys is clearly a contributing factor

You May Have Heard……that if you don’t update your DNS keys every thirty days, your domain failsTell this to an ops guy, and he’ll literally remove you from the premisesDKI cannot depend on any technology that requires manual maintenance on pain of total failurePhreebird’s keys will expire in 2100 (obviously configurable)But don’t we want to make keys go bad?

Sure!The right place to do this is in the chain to root, not at the endpoint.org has a DS record – “this is how you can recognize Travis”This record is signed for some number of days (30 now, could be 5)On key rotation, or an emergency event, this record is updated“Heads up, Travis cut his hair, he’s got a mullet now”The “infinite lifespan” key is now of no value to the attacker

What If The Clock’s Wrong?In DNS, all time is relative“This value is good for the next 600 seconds”In DNSSEC, all time is absolute“This value is good until August 1st, 2010, 0630 GMT”This is necessary to prevent replay attacks600 seconds from now is not 600 seconds from a month agoBut what if you think it’s August 15th, 2010?

Well then…Either:A) The Internet stops resolvingB) Ops disables expiration checkingOPS IS KINGIf we want expiration checking, we have to manage timeCouldn’t we use NTP (the Network Time Protocol)?

Chicken and EggHow do you authenticate time?It’s a cross organizational auth requestEven if you have your own time servers, what do they sync against?Couldn’t we use DNSSEC to bootstrap NTP?We’re trying to use NTP to bootstrap DNSSEC!Chicken and Egg!

Solution: DnsTimeBasic idea: Simple timestamp, signed by some unique domain chaining to the DNSSEC rootSay, “dnstime.” or somethingThere be politics here, don’t want to speculate on where exactly this would liveRetrieve the timestampA) On expiration errorB) No more than once every 24 hours

There’s An AttackCan anyone see it?

Replay!Two weeks ago, attacker got a signed record with a short expiration, and the root-chained timestampNow, he can replay those things forever and ever……unless we add a nonce.

Replay DefeatOn receiving an expiration error, resolve dnstimeIf the resulting time indeed suggests local time is wrong, requery for 74A0CCEB1E3E.dnstimeThis record is online-signed just for that particular querySince the response is both signed and unique, the name server can add an offset to its clock to compensate for local time differential from global truth

Towards TheDomain Key InfrastructurePerhaps DNSSEC is easy to deploy. But is it useful?Distributed authentication is only interesting if it provides end to end semantics“My desktop to your server”Isn’t DNSSEC only designed to secure the links between recursive name servers, and not endpoints like desktops?

The Basic Mode: The AD BitDNS responses have a bit referred to as ADMeaning: “The name server you were speaking to validated the DNSSEC status of this record”So?Starbucks, I like your coffeeI don’t trust you to tell me the appropriate certificate for my bankNo application on earth is going to alter the user experience based on the AD bit

How Do We Get Full Keys To Your Desktop, Laptop, or Phone?ChasingTracingWrappingPacking

Chasing: Going Up The StackEach signature (“RRSIG”) names its sourceSo, we go up the stack“www.foo.com was signed by foo.com”“foo.com” was signed by “com”“com was signed by the root”“I trust the Root, therefore I trust www.foo.com”

LDNS makes it easyThis is about ten lines of code in ldnsInstantiate a resolver w/ NS listProvide the root keyDo a resolveExtract the answers“Build the data chain” (ldns_dnssec_build_data_chain)“Derive the trust tree” (ldns_dnssec_derive_trust_tree)Check for success (ldns_dnssec_trust_tree_contains_keys)

Two Problems With Chasing1) Requires a decent number of round trips to the DNS serverSomewhat slowBeing fixed (we think) with what Paul Vixie and I refer to as “Superchase”RD=1 CD=1Server returns not just the bottom of the chain, but all the way upPossible configuration of how far up – “Heh, I already have this com DS, can you just get me there?”

The Other ProblemNoncompliant networksLocal resolver might not respond properly to CD=1Local network might block DNSSEC trafficThis stuff will work 80-90% of the timeThat’s not enoughOps is King

Tracing: Going Down The StackChasing: Given a domain, go up to rootTracing: Given root, get down to the domainThis is basic recursion, the fundamental system by which DNS servers work normallyUnbound is the nameserver built upon ldnsUnbound can be integrated via libunbound, and is itself only a few lines of code as well

Tracing in LibUnboundEven fewer lines of code!Create an unbound context (ub_ctx_create)Add a Trust Anchors file (ub_ctx_add_ta_file)Containing just the root Resolve a domain (ub_resolve)If result->secure==1, read the output from result->data.

Issues With Tracing1) Entirely bypasses the local cache, increasing load on the root and TLD serversSomewhat acceptable if the cache on the end host is very long livedAlmost entirely unacceptable if it’s short lived / flushed for each call(This was the problem with DNSCurve – if you used it to achieve end to end trust, the end hosts needed to talk to the roots directly in order to function)

Those Again2) The middleboxen are still a problemThey do bad things to a lot of traffic! What can you do?Respect Skype’s Law

Wrapping: DNS over HTTPNot complicated – instead of doing DNS over UDP packets that might get intercepted, talk to a custom DNS server that exposes an HTTP endpointGET requests w/ Base64 encoded DNS requests8 bit clean responsesPhreebird implements this

Performance DataSo, how much of a perf hit does DNS take, running over TCP and then HTTP?

Well, it ain’t slower.It might even be faster.# DNS over UDP./queryperf -d target2 -s 184.73.1.213 -l 10… Queries per second: 3278.676726 qps# DNS over HTTPab -c 100 -n 10000 http://184.73.1.213/Rz8BAAABAAAAAAAAA3d3dwNjbm4DY29tAAABAAE=… Requests per second: 3910.13 [#/sec] (mean)

Could Be Wrong!Paul Vixie thinks I am“Being wrong just means the world is more interesting than you thought it was.”Even with a significant penalty, superchase over HTTP should work reasonably well thoughRecursion Ventures will be hosting a DNS over HTTP service in the Cloud within the next few weeks

Wrapping: Brett Watson’s ObservationBrett Watson is a really smart KiwiHe was quite the skeptic about DNSSECSo was I, so we got along wellHis exact quote: “You have to be willing to separate the content of DNS from the transport of DNS”This is a fairly profound pointLed to an interesting concept

X.509X.509 normally carries chains to one of a few hundred CA roots, through possibly one of some unknown thousand god-mode IntermediatesThis is part of why X.509 didn’t workOther partsUnable to reliably delegate – you can’t get a cert for .domain.com that lets you sign other certsUnable to exclude – if Verisign gives you a cert for a domain, so can everyone elseSee 2009 “Black Ops of PKI” for details

X.509 ReloadedX.509 could also carry the DNSSEC chain.SSL already moves X.509DNS over X.509 over SSLTake that, hotel miniboxenAlso, super high performance!Implementing this requires:Extracting all the keys of the full trust chainNot too hard – build a trust chain in ldns, then iterate through it extracting all unique keysValidating the morass of key material you’re left withThat’s being a bit tricky – requires some rearchitecture

Or, you could just be Google’s Adam Langley… [0]

Or, you could just be Google’s Adam Langley… [1]

NOTEThis is an unofficial private build of Chrome!Google is not at all committed to DNSSEC, DKI, or X.509 Certificate embedding!This is just Adam and I seeing what is possible And now, I think it’s a good idea to start talking about actual applications.

Where Do We Implement The DKI?PhreeShell: Federated Identity For OpenSSHThis was the demo at the start of the talkBased on the idea that end nodes should validate identities, not public keysToday: Identities instead of keys in authorized_keys2Tomorrow: LDAP backend (similar to FedSSH)“Let everyone at support.vendor.com into all the machines in the vendor.com group”

The Dirty Secret Of FederationPeople have been selling this stuff for yearsBut nobody’s deploying it in large amountsOPS IS KINGThree choicesM to N complexity: Every group has painful and expensive meetings with every other groupThe Risk Of The Kingmaker: One group is trusted by all others as the identity manager, and that one abuses his role (lets not name names)Key Bleed: Everybody has to trust way too many keyholders not to abuse their powers.

The Fourth PathThe Silent OverseerDNSSEC: A single root keyholder, incredibly constrained by both external political constraints and a technical delegation system designed to suppress operational dependencyDKI: Federation that will actually work

So, do we add ldns/libunboundto each package, one by one?Eventually, possiblyBut in the short term? To prove value?On Linux/Unix, SSL is handled via OpenSSLSpecifically, X509_verify_certA nice and self contained library call…hmm…

PhreeLoad: Adding DNSSEC Verification To OpenSSL Apps Via LD_PRELOADPrior Work: libval_shim from Russ Mundy @ SpartaGreat work!Two major differentiators1) Written before the root was signed, so no provisions for chasing a signature down to the root2) Validated the results of a DNS query – which might just be an IP address, attackable via other meansPhreeLoad operates at a different layerGiven software that’s attempting to achieve end-to-end security, replace/augment the auth layer with DNSSEC

Debugging – Just Making Sure This Thing Is Working

The (DELIBERATELY INCORRECT) Schema# dig +short _ssl_absolute.www.hospital-link.org TXT "'5e0905b0eafd35d59f1b178727d4eaadd06c415d'"

…and if we break DNS…_ssl_absolute.www.hospital-link.org. IN TXT 'AAAA05b0eafd35d59f1b178727d4eaadd06c415d'

(When fixed, curl works. So does wget)

All OpenSSL apps means All OpenSSL AppsPostfixPostgresMySQLApacheWant to start working on client certificates that actually work? Much easier now that we have a signed rootWelcome to DKI

But Lets Keep The Focus On BrowsersOpenSSL is great, but browsers don’t use itIE: CryptoAPIFirefox / Chrome: NSSAlso, no LD_PRELOAD on Windows*whistles innocently*What to do?

HTTPS ProxyingPDP @ GNUCitizen put together httpservers.py, which uses Browser Secure Proxy functionality to inject into HTTPS sessions (assuming appropriate keys are set up)Based on the work of UZUKI Hisao, Andres Riancho, and Dave AitelWhat is sent:CONNECT www.site.com:443 HTTP/1.1

Phoxie: Remote Validation Proxy For Production Browsers1) We can provide the client a custom root certificate2) Before the SSL connection is established, we get the name of the domain the client would like to connect to3) For each connection, we can provide a custom root-signed certificateWildcards don’t work nearly as well as they used toSorry about that 4) The browser will always trust us. We, however, will only proxy if the real server passes SSL validationOf course, we have PhreeLoad up and running, so SSL validation includes “DNSSEC is happy”

Black Ops of Fundamental Defense:

More Related Content

Viewers also liked

Similar to Black Ops of Fundamental Defense:

Recently uploaded

Black Ops of Fundamental Defense:

Editor's Notes