merneobux

SecuritybyAnyOtherName:OntheEffectivenessofProviderBasedEmailSecurityIanFoster,JonLarson,MaxMasich,AlexC.
Snoeren,StefanSavage,andKirillLevchenkoDepartmentofComputerScienceandEngineeringUniversityofCalifornia,SanDiego{idfoster,mmasich,snoeren,savage,klevchen}@cs.
ucsd.
eduABSTRACTEmailasweuseittodaymakesnoguaranteesaboutmessagein-tegrity,authenticity,orcondentiality.
Usersmustexplicitlyen-cryptandsignmessagecontentsusingtoolslikePGPiftheywishtoprotectthemselvesagainstmessagetampering,forgery,oreaves-dropping.
However,fewdo,leavingthevastmajorityofusersopentosuchattacks.
Fortunately,transport-layersecuritymechanisms(availableasextensionstoSMTP,IMAP,POP3)providesomede-greeofprotectionagainstnetwork-basedeavesdroppingattacks.
Atthesametime,DKIMandSPFprotectagainstnetwork-basedmes-sageforgeryandtampering.
Inthisworkweevaluatethesecurityprovidedbytheseproto-cols,bothintheoryandinpractice.
Usingacombinationofmea-surementtechniques,wedeterminewhethermajorproviderssup-portsTLSateachpointintheiremailmessagepath,andwhethertheysupportSPFandDKIMonincomingandoutgoingmail.
Wefoundthatwhilemorethanhalfofthetop20,000receivingMTAssupportedTLS,andsupportforTLSisincreasing,serversdonotcheckcerticates,openingtheInternetemailsystemuptoman-in-the-middleeavesdroppingattacks.
Atthesametime,whileuseofSPFiscommon,enforcementislimited.
Moreover,fewofthesendersweexaminedusedDKIM,andfewerstillrejectedinvalidDKIMsignatures.
Ourndingsshowthattheglobalemailsystemprovidessomeprotectionagainstpassiveeavesdropping,limitedprotectionagainstunprivilegedpeermessageforgery,andnopro-tectionagainstactivenetwork-basedattacks.
Weobservethatpro-tectionevenagainstthelatterispossibleusingexistingprotocolswithproperenforcement.
1.
INTRODUCTIONFewuserssignorencryptemailtoday,despitereadysoftwaresupportforPGPandS/MIME.
Thevastmajorityofemailuserscontinuetosendemailintheclear,withnosafeguardsagainsteavesdropping,tampering,orforgery.
Despiterisingpubliccon-cernaboutmasssurveillance,universalend-to-endemailsecuritystillremainselusive.
Whileuseradoptionofemailsecuritytoolshasbeenpoor,useoflower-layersecuritymechanisms,namelyTLS,SPF,andDKIM,Permissiontomakedigitalorhardcopiesofallorpartofthisworkforpersonalorclassroomuseisgrantedwithoutfeeprovidedthatcopiesarenotmadeordistributedforprotorcommercialadvantageandthatcopiesbearthisnoticeandthefullcitationontherstpage.
Copyrightsforcomponentsofthisworkownedbyothersthantheauthor(s)mustbehonored.
Abstractingwithcreditispermitted.
Tocopyotherwise,orrepublish,topostonserversortoredistributetolists,requirespriorspecicpermissionand/orafee.
RequestpermissionsfromPermissions@acm.
org.
CCS'15,October12–16,2015,Denver,Colorado,USA.
Copyrightisheldbytheowner/author(s).
PublicationrightslicensedtoACM.
ACM978-1-4503-3832-5/15/10.
.
.
$15.
00.
DOI:http://dx.
doi.
org/10.
1145/2810103.
2813607.
hasbeenontherise.
Googlerecentlyreported59%adoptionofTLSbysendingand79%byreceivingservers,andourownmea-surements(reportedinthiswork)echothesestatistics.
Weareledtoconsiderwhethersomeofthesecuritygoalsofend-to-endtoolslikePGPcanbesatisedusingtheseprotocols.
Remarkably,whenusedcorrectlyandenforced,TLSandDKIMwithDNSSECcanpro-tectagainstactivenetwork-basedman-in-the-middleattacks.
Theseguarantees,howeverrequiretrustingtheprovider,somethingthatisexplicitlynotnecessarywhenend-to-endsecuritymechanismslikePGPareused.
Whetheremailprovidersaretrustworthyisaseparate,nolessimportant,questionwhichwedonotconsiderinthiswork.
Werec-ognizethatforsomereaders,anysolutionthatrequirestrustinganemailproviderisunacceptableasamatterofprinciple.
Forothers,trustinganemailproviderisafaitaccompli—usersalreadytrusttheirprovider.
(Infact,evenGoogle'sEnd-to-Endinitiative,basedonOpenPGP,delegateskeyvericationtocentralizedproviders.
1Ourwork,then,shouldbeviewedasansweringthequestionofwhatguaranteesTLS,DKIMandSPFcanprovide,iftheproviderisalreadytrusted.
Ofcourse,useoftheseprovidersecuritymecha-nismsdoesnotprecludeusersfromusinganend-to-endmechanismaswell.
Ifsecuringemailagainstnetworkattacksispossibleusingexist-ingprotocols,thenwemustaskwhethertheseprotocolsarebeingusedinawaythatachievesthis.
Thegreaterportionofthispaperisdevotedtothisquestion,namelywhetherthecurrentdeploymentofTLS,DKIM,andSPFprovidestheselevelofsecuritypossibleun-deridealconditions.
Toanswerthisquestion,wemeasuredthelevelofsupportforTLS,DKIM,andSPFamongtopemailprovidersanddeterminedwhethertheyenforcecorrectprotocoluse.
BecauseDKIMandSPFdependonDNSforprotectionagainstanactive(man-in-the-middle)attacker,wealsomeasuretheuseofDNSSECamongproviders.
Wereliedonacombinationofactiveprobingtechniquestocarryoutthemeasurementstudy,somenewandofindependentinteresttotheInternetmeasurementcommunity.
TodeterminehowmuchprotectionTLSprovidedagainsteavesdropping,wedetermined,wherepossible,whetherTLSwassupportedandusedalongeachhopalongamessagepathbetweentwoproviders,andwhetherservercerticatecheckingwasdone.
Forhopsinternaltoaproviderwherewecouldnotinteractwithserversdirectly,wereliedonin-formationinReceivedemailheaders.
ForDKIMandSPF,wemea-suredsupportonthesendingendbyexaminingmessagesgeneratedbyproviders(DKIMonly),retrievingthenecessaryDNSrecords,andnotingsupportforDNSSEC.
Onthereceivingend,wemea-1End-to-EndreliesonamechanismakintoCACerticateTransparencytomitigatetheriskofimpersonation,however,theeffectivenessofsuchamechanismhasseenlittleevaluation.
suredprovidervericationofDKIMsignaturesandenforcementofSPFpoliciesbygeneratingmailofvaryinglevelsofconformance.
Wheremeasurementcouldbeautomated,weprobedthetopmillionmailservers(rankedbytheirprevalenceamongusersintheAdobeleakeduserdatabase).
Whenevermanualinteractionwasnecessary,weexaminedthetop22emailproviders(basedonAdoberank)aswellasselectemail-generatingservices(e.
g.
amazon.
com).
Inbrief,wefoundthat,whilemanyproviderssupportTLSformailsubmission,transport,anddelivery,allbutonedonotverifycerticates,makingthemvulnerabletoanactiveattacker.
WealsofoundthatwhileDKIMprovidesmessageintegrity,itisdependentonDNS,whichisvulnerabletoactiveattacks.
Thenalpartofthispaperbrieyaddressesthechangesnec-essarytoimprovethecurrentstateofaffairs.
Forsomeproviders,therststepistodeploytheseprotocols.
Asweshowinthemea-surementstudy,ofthefourprotocols,DNSSEChasthelowestde-ployment,evenamongthetopproviders.
Thesecondstep,enforce-ment,islessstraightforward.
Enforcingasecuritypolicyneces-sarilymeansrejectingnon-conformingmail,anactionthatdirectlyimpactstheuserexperience.
Inthelastpartofthepaper,wediscussthetrade-offsinvolvedinenforcingadherencetoeachprotocol.
Ourmaincontributionsare:OAmethodologyfordeterminingTLSusealongthefullmessagepathbetweentwoproviders.
Weusebothdi-rectmeasurement(interactionwithserversalongthepath)andinformationrecordedinmailheaderstode-terminewhetheraserverusesTLS,andinthecaseoftheformer,whetheritdoescerticatechecking.
OAnanalysisofthecurrentstateofTLS,DKIM,SPF,andDNSSECdeployment.
WereportonthelevelofTLSsupportof96incomingmailserversand302938outgoingmailserversofpopularInternetservices.
WealsoreportonthelevelofDKIM,SPF,andDNSSECsupportamongtheseservers.
OWedescribehowcorrectuseoftheaboveprotocolscanprovidemessagecondentialityandintegrityinare-laxedthreatmodel.
Weidentifythechangesinthecur-rentInternetemailecosystemnecessarytoprovidethislevelofsecurity.
Therestofthepaperisorganizedasfollows.
Section2describesthethreatmodelthatthisworkismostlyconcernedwith.
Section3providesthenecessarytechnicalbackgroundfortherestofthepa-per.
Section4describesourmethodologyusedinouranalysis.
Sec-tion5providesthenalanalysisofourcollecteddata.
Section6listsotherworkthathasbeendoneonthesamesubject.
Section7discussestheimplicationsofourresults.
Section8concludesthepaper.
2.
THREATMODELThesubjectofthispaperisthecondentiality,integrity,andauthenticityofemailcommunicationsachievedwhenTLSisusedalongthemessagepathandDKIM,SPF,andDNSSECbytheendproviders.
Inthissectionwedescribethethreatmodelweconsider,namelynetwork-basedattacks.
Inparticular,weconsiderthreekindsofnetworkattacker:Active.
Anactiveattacker,alsocalledaman-in-the-middleattacker,canobserveandmodifyallpackets,andinjectarbitrarypackets,betweenatargetandtherestoftheInternet.
Passive.
ApassiveattackercanobservebutnotmodifythetrafcbetweenatargetandtherestoftheInternet.
(Weconsiderpassiveattacksoncondentialityonly.
)Figure1:Typicalpathofamailmessagefromsendertoreceiver.
Peer.
AnetworkpeerisanordinaryhostconnectedtotheInternet,capableofsendingarbitrarypacketsandreceivingpacketsforwhichitisthedestination.
Otherthanthedegreeofnetworkaccessabove,weassumenootherattackercapability.
Inparticular,weassumethattheemailprovidersinvolvedaretrustedanddonotcolludewithanetworkattacker.
Asdiscussedabove,theassumptionofatrustedproviderisnotpre-scriptiveandnotmeanttosuggestthatprovidersaretrustworthyorshouldbetrusted.
Rather,itshouldbeunderstoodasalogicalan-tecedentofourresults:iftheprovideristrustedandtheprotocolsinquestionareusedcorrectly,thenacertainlevelofsecurityagainstanetworkattackercanbeachieved.
3.
BACKGROUNDInthissectionwedescribethelevelofsecurityachievablewhenTLS,DKIM,SPF,andDNSSECareusedcorrectly.
Ourgoalisalsotoidentifythosepointsoftheprotocolwherefailurewouldcompromiseoverallsecurity.
InSection5wefocusonthesepointstoassessthereal-worldstateofaffairs.
Weexpectthatmostreadersarefamiliarwiththeprotocolsinquestion,however,theAppendixprovidesthebackgroundneces-saryfortherestofthepaper.
3.
1SecurityPropertiesThesecuritypropertiesofconcerntousaremessagecondentiality,messageauthenticity,andmessageintegrity.
Putplainly,thesetranslateintothefollowing:Condentiality.
CananattackerreadamessageAuthenticity.
CananattackerforgeamessageIntegrity.
CananattackermodifyamessageWeconsiderattacksoncondentialitybyactive(man-in-the-middle)andpassiveattackers,attacksonauthenticitybyactiveandpeerat-tackers,andattacksonintegritybyactiveattackersonly.
There-mainingcombinationsofattackerandattackedsecuritypropertyareexcludedbydenition.
Forexample,apassiveorpeerattackercannotcompromisemessageintegritybecauseshedoesnot(bydef-inition)havetheabilitytomodifyamessage.
3.
2MailPathAtypicalpathofamailmessageisshowninFigure1.
Startingwiththesendinguser'sMailUserAgent(MUA),themessageisrsttransmittedtothesender'smailprovider(a)usingtheSimpleMailTransferProtocol(SMTP),usingHTTPviaaWebinterface,or,insomecases,usingaproprietaryprotocol.
Afterprocessingin-sidetheprovider(b),themessageistransmittedtotherecipient'sprovider(c)usingSMTP.
Afterreceiverprocessing(d),whichmayincludespamltering,themessageisdeliveredtotherecipientus-ingtheInternetMessageAccessProtocol(IMAP),thePostOfceProtocol(POP),HTTPviaaWebinterfaceorusingaproprietaryprotocol.
3.
3CondentialityAnetwork-basedeavesdroppermaygainaccesstoamessageduringsubmission,providerprocessing,transferbetweenproviders,anddelivery.
Thestandardprotocols,namelyHTTP,SMTP,IMAP,andPOP,usedalongthemailpathdefendagainsteavesdroppingus-ingTLSencryption.
Whileinprinciple,proprietaryprotocolsusedonthesubmissionanddeliveryhops,labeled(a)and(e),respec-tively,inFigure1,mayusenon-standardcryptographicprotocols.
SomeprovidersalsouseSMTPinternally,hops(b)and(d),how-everthereisnorequirementtodoso.
Communicationinternaltoaproviderhasusuallybeenconsideredsecure,sinceitiscommontocollocateaMSAandMTA,orevencombinethetworolesinasinglehost.
Atlargerproviders,internalhopsmaybelocatedingeographicallyseparatedatacenters.
2Againstapassiveattacker,itissufcienttouseTLSonallat-tackeraccessiblelinks,providedastrongciphersuiteisused.
Inparticular,useoftheSTARTTLSoptionordirectTLSencapsula-tionwithSMTP,IMAP,andPOPorHTTPSwillprotectagainstapassiveattacker.
Provider-internallinksmaybesecuredphysicallyorusingTLSinthesamemanner.
Sinceapassiveattackercannotmodifynetworktrafc,itispossibletoexchangekeyssecurely;defenseagainstapassiveattackerdoesnotrequirecerticateveri-cation.
Anactiveattacker,ontheotherhand,canimpersonateeachsideofaconnectiontotheother.
Defendingagainstsuchaman-in-the-middleattackrequiresthesendertoverifytheidentityofthere-ceiver.
IfanactiveattackercangaincontrolofanyhopalongthemessagepathandeitherTLSisnotusedonthathop,orTLSisusedwithoutservercerticateverication,theattackerwillbeabletoimpersonatethereceiverandgainaccesstothemessage.
WenotethatDNSintegrityisnotrequiredforTLSifthecom-monname(CN)orthesubjectAltNameischeckedagainstthein-tendedserverdomainname(ratherthanIPaddress).
Evenifanattackertricksaclientintocontactingaserverunderhercontrol,theclientcancheckthatcerticateprovidedbytheservermatchesthehostnameoftheintendedserver.
3.
4AuthenticityToforgeamessage,anattackermustbeabletoinjectitatsomepointinthemailpathinasuchawaythatitisacceptedbythereceiver.
Toforgeamessageatsubmission(a),theattackermustbeabletoauthenticateastheusertotheprovider,usuallyusingapassword.
Anactiveattackercantricktheuserintorevealinghispasswordbyimpersonatingtheprovider(ateitherthesubmissionordeliveryend).
Secrecyofthepasswordthusrequiresservercer-ticatecheckingbytheuseragent.
Inaddition,failuretoverifytheservercerticateoftheMDAwouldallowaactiveattackertoim-personatetheMDAand,inadditiontolearningthepassword,injectaforgedmessagetotheuserondelivery(e).
Messageauthenticity(andintegrity)insideaprovidercanbeachievedbyphysicallyse-curingthelinksorwiththeuseofclientcerticates.
Thehopmostvulnerabletoforgery,isthehopbetweenproviders(c).
AnincomingMTA,uponreceivingamessage,mustbeabletodetermineifthemessageoriginatedfromaproviderauthorizedtosendemailwiththesenderemaildomainappearinginthemessage.
Recallthatourthreatmodelpositsanetwork-basedattacker,soitissufcientthatverifythatanincomingmessageoriginatedatthesender'sprovider;thesender'sproviderensuresthatthesubmittingMUAisauthorizedtosendemailfromtheusernamedasthemes-sagesender.
BothDKIMandSPFprovideprotectionagainstforgery.
DKIMprovidesamessagesignaturecoveringthebodyandasubsetofmessageheaders.
Thesignatureiscreatedbythesender'sproviderandisintendedtoconvincetherecipient'sproviderthatthemes-2LeakeddocumentsindicatethattheNSAhasbeeneavesdroppingonthe(unen-crypted)inter-datacentertrafcofbothGoogleandYahoo[4].
Inlightofthis,manyprovidershavemovedtoencryptinginter-datacentertrafc[1].
sageisauthenticandprovideprotectionagainsttampering.
SPF,ontheotherhand,allowsaprovidertoidentify(bydomainnameorIPaddress)asetofauthorizedsendersforthedomain.
Anincom-ingMTAcanverifythattheoutgoingMTAsendingthemessageisauthorizedtosendemailforthedomain.
Inprinciple,SPFcanprotectagainstforgerybyapeerattackerbyonlyallowingcertainnetworkhoststosendemailonbehalfofadomain.
ApeerattackcannotimpersonateahostontheallowedlistbecauseshecannotcompleteaTCPconnectionfromanallowedpeer.
Anactiveattacker,ontheotherhand,canimpersonateanyhost.
SPF,thus,providesnoprotectionagainstanactiveattacker.
DKIM,ontheotherhand,reliesonadigitalsignaturetopro-tectthemessage,includingthesenderaddress.
Assuch,DKIMcanprotectagainstmessageforgeryandtampering,evenagainstanactiveattacker.
Itisworthconsidering,then,whatisrequiredofanattackertoforgeaDKIMsignature.
DKIMreliesonDNSforkeydistribution.
Thekeyusedtogenerateaparticularsigna-tureisprovidedinaTXTrecordforanameinaspecialsubdo-mainofthesender'sdomain.
Thus,amessagefromexample.
commustbeveriedusingapublickeypublishedintheTXTrecordofselector.
__domainkey.
example.
net,whereselectorisatokenprovidedwiththesignature.
AnattackerthatcanforgetheTXTrecordretrievedbytheverifyingserverwould,thus,beabletogenerateavalidsignatureforanotherdomain.
TheintegrityofDNSresponsescanbesecuredusingDNSSEC.
IfthesendingproviderusesDNSSEC,thereceivingprovidercanobtaintheDKIMsigningkeysecurelyorreceivesignedconrma-tionthatarecorddoesnotexist.
ThecombinationofDKIMandDNSSECcan,thus,beusedtodefendagainstforgeryofsignedmessages.
IfanattackeromitstheDKIMsignature,thereceivermustdeterminewhetherthemessageisaforgery,orwhetherthelegitimatesenderforthedomaindoesnotuseDKIM.
Twosimi-larmechanismsexistfordoingso:AuthorDomainSigningPrac-tices(ADSP)andDomain-basedMessageAuthentication,Report-ing,andConformance(DMARC).
Bothallowaprovidertopublishitsmessagesigningpolicyandrequestedtreatment.
ItisalsopossibletoensuremessageauthenticityusingTLSclientauthentication.
Wearenotawareofanyprovidersrelyingonthismechanisminsubmission,delivery,orprovider-to-providertrans-port.
3.
5IntegrityIntheabsenceofanyprotection,anactiveattackercanmodifyamailmessagealonganyofthehopsinFigure1.
DKIMsignaturescanbeusedtoprotectmessagesfromtamperingintransit.
Asdis-cussedabove,thisrequiresDNSSECifanattackercantamperwiththereceivingprovider'sDNStrafc.
3.
6EnforcementBothSPFandDKIMweredevelopedprimarilyasameanstoghtspam.
Byimpersonatingauseratalargeprovider,aspam-mercouldimprovehisdeliveryrate;DKIMandSPFpreventsuchforgery.
Inthisrole,bothSPFandDKIMareregardedassignalstoaspamlterthattheincomingmessageislegitimate.
Allotherthingsbeingequal,amessagewithaDKIMsignatureshouldbelesslikelytobeidentiedasspamthanonewithout.
Itistempt-ing,therefore,forsenderstoregardDKIMandSPFasoptionalmechanismstoimprovedeliverabilityforsomemail,ratherthanassecuritymechanisms.
Forthereceivertoo,limitedadoptionofDKIMmakesitinadvisabletoplacetoogreataweightonthere-sultsofDKIMsignatureverication.
ADSPandDMARCprovideameansforaprovidertoadvertiseitsmailauthenticationpolicy.
However,ADSPandDMARCareneweradditions;untiltheyarePropertyActivePassivePeerCondentialityTLSwithCertVerif.
TLS—AuthenticityDKIM*andDNSSEC—SPForDKIM*IntegrityDKIM*andDNSSEC——Table1:Minimumprotocolrequirementsforcondentiality,authenticity,andintegrityagainstactive,passive,andpeerattackers.
A"—"entryindicatesaninapplicablecom-bination.
*Note:whileDKIMistheoreticallysufcient,asusedtoday,itisalsonec-essarytoadvertiseastrictpolicyusingDMARC.
widelyadopted,areceiverwillhavenowayofpositivelydetermin-ingthatamessagefromaprovidershouldbesigned.
3AnalternativetoADSPandDMARCisforproviderstobilater-allydisseminatetheirsigningpoliciestoeachother.
Withexplicitagreement,DKIMsigningpoliciescanbeenforcedaggressively.
Weknowofatleastonecasewherethishappensalready:GMailwillnotacceptemailfromeBayorPayPalifitisnotsigned[6].
3.
7ImplicationsWehavearguedthatTLSwithservercerticatecheckingandDKIMwithDNSSECcanbeusedtosecureemailagainstevenanactivenetworkattacker.
Table1summarizestheminimumrequire-mentsforeachsecuritypropertyandclassofattacker.
Inparticular,TLSmustbeusedwithservercerticatevericationandDKIMmustbeusedwithDNSSECtoprotectagainstanactiveadversary.
Intheabsenceofbilateralinter-provideragreements,sendingprovidersshouldpublishasigningpolicyandreceivingprovidersshouldnotacceptunsignedorincorrectlysignedmailfromprovidersadvertisingapolicyofsigningalloutgoingmail.
Sofar,wehavebeenconcernedwiththeidealcase,whatsecurityguaranteescanbemadeinthepresenceofanetworkadversaryifTLS,DKIM,andDNSSECareusedcorrectlywithanaggressiveenforcementpolicy.
Intheremainderofthispaper,weexaminewhatactuallyhappens.
Thefollowingsectiondescribesourmea-surementmethodology,andthesectionfollowingdescribesoutre-sults.
Inparticular,wereportonboththedeploymentoftheaboveprotocols,whetherprovidersusethemcorrectly,andwhethertheyenforcetheircorrectuse.
4.
METHODOLOGYInthissection,wedescribeourmeasurementmethodology.
Thesubjectsofourstudyareemailprovidersandmajorservicesthatgenerateemail(e.
g.
e-commerceandonlinesocialnetworks).
Foreachsubjectconsidered,wedeterminedhoweachofthesecurityprotocolsinquestionwereused.
Roughlyspeaking,ourmeasurementmethodscanbedividedintotwokinds:thosethatcouldbefullyautomatedandscaledeas-ily,andthosethatrequiredsomemanualinteraction.
Forthelatter,weusedasetof302938majoremailprovidersandemailgenera-tors,whilefortheformer,weusedamuchlargersetofamillionpopularprovidersoccurringintheAdobeleakandtheAlexatopmillionWebsites(aspotentialemailgenerators).
Todeterminewhetheremailsentbetweentheseservicesispro-tectedfromanetworkattacker,weexperimentallydetermineifeachhopalongthemessagepathisproperlysecured.
Forhopsthatareexternallyaccessible,namelyMUAtoMSA,MTAtoMTA,andMDAtoMUA,denoted(a),(c),and(e)inFigure1,wein-teractwiththeendpointsdirectlytodeterminetheirTLSbehavior.
Forhopsinternaltoaprovider,werelyoninformationreportedintheReceivedmailheaders.
Ourdataconsistsoftwomeasurement3Areceivercouldinferasigningpolicybasedonpreviousmessagesfromtheprovider.
However,itcannotbetakenasareliableindicationthatallmailshouldbesigned.
DomainCountryFrequencyCumulativehotmail.
com29.
82%29.
82%gmail.
com18.
86%48.
68%yahoo.
com14.
22%62.
91%aol.
comUS2.
83%65.
74%gmx.
deDE1.
06%66.
80%mail.
ruRU1.
05%67.
85%yahoo.
co.
inIN0.
99%68.
84%comcast.
netUS0.
89%69.
73%web.
deDE0.
88%70.
61%qq.
comCN0.
71%71.
32%yahoo.
co.
jpJP0.
71%72.
02%naver.
comKR0.
47%72.
49%163.
comCN0.
46%72.
95%twc.
comUS0.
38%73.
33%libero.
itIT0.
34%73.
67%yandex.
ruRU0.
32%73.
99%daum.
netKR0.
27%74.
26%cox.
netUS0.
26%74.
52%att.
netUS0.
22%74.
73%wp.
plPL0.
20%74.
93%pacbell.
netUS0.
08%75.
01%sohu.
comCN0.
04%75.
05%Table2:ThetopemailhostsfromtheAdobelist.
RowscontainalluserswhouseanyMTAsharedbythedomain.
experimentsaboutayearapart(March2014andFebruary2015),givingusaviewintothechangesinTLSuse.
TLSuseduringaSMTPsessionrequiresbothclientandserversupport.
Inparticular,aservermustoffertheSTARTTLSoption,andtheclientmustissuetheSTARTTLScommand.
Thus,wecaninferhowaclientandaserverarelikelytointeractbytestingeachseparately.
IfaparticularserverofferstheSTARTTLSoptiontouswhenweconnecttoit,andaparticularclientissuestheSTARTTLScommandwhenitconnectstous,wecansaythat,atleastnom-inally,thetwowilluseTLSwitheachother.
Wesaynominally,becauseeitherserver,client,orbothmaybeconguredtoactdif-ferentlywhencommunicatingwitheachotherthanwhencommu-nicatingwithus,orthetwomaybeusingincompatibleTLSim-plementations.
Totestthispremise,wetestedhowselectprovidersinteractionwitheachother,asdescribedinSection4.
8.
Werstdescribehowwechosethesetofserviceswetested.
4.
1SubjectSelectionForourconclusionstobeuseful,thesetofmessagepathsweanalyzeshouldbebroadlyrepresentativeofthemessagepathsseenintheglobalemailsystem.
TheidealsetcasewouldbeasetofpathsformedbyuniformlysamplingmessagepathsontheInter-net.
Unfortunately,thisisimpossibleinpractice.
Toapproximatetheidealsample,wecompiledalistofpopularemailproviders(orsimplyproviders),emailgeneratingservices(generators).
Wethenusedfragmentsofmessagepathsoriginatingorterminatingattheseservicestopiecetogetheracompletepictureofpossiblemessagepathsbetweenthem.
Forverication,asubsetofthesepathsarematerializedexplicitly,asdescribedinSection5.
3.
4.
1.
1PathUniquenessThepathtakenbyamessagebetweenagivensenderandrecip-ientisnotuniqueduetoloadbalancingandemailinfrastructureevolution.
Howeveratagiventime,wefoundmessagepathstobestablewithrespecttoTLSusecharacteristics.
Thatistosay,char-acteristicsofTLSusealongthepathdidnotchangeduringthemeasurementperiod.
Wenotewherethiswasnotthecaseinouranalysis.
4.
1.
2ProviderListWecreatedthesetofpopularemailprovidersbasedonthetop1millionemailaddressdomainsoccurringintheleakedAdobeuserdatasetofSeptember2013.
(Thefulllistconsistsof152millionemailaddressspanning9.
2milliondistinctdomains.
)Anumberoflargeprovidersmayservicemorethanonedomainname;forexample,hotmail.
comandoutlook.
comaredomainsusedbythesameservice,namelyMicrosoft'sOutlook.
com.
WegroupedsuchdomainsintoasingleservicebasedontheincomingMTAsforthedomain.
Specically,foreachdomain,weretrieveditsDNSMXrecords.
NotalldomainshadMXrecords,andsomehadmorethanone.
(IftherewasnoMXrecord,wetookthedomainnameitselfastheincomingMTAaddress,perRFC5321.
)Wethenresolvedallhostnames,toarriveatasetofIPaddressesofincomingMTAsservicingadomain.
AllDNSlookupsweredoneinFebruary2015.
AnydomainswithatleastonecommonIPaddressweregroupedintoasingleservice.
Wecalltheresultinglisttheproviderlist.
4Someoftheexperimentsrequiredmanualinteractionwithaser-vice.
Forthese,wetook22ofthetopprovidersfromtheAdobeproviderlistwithwhichwewereabletocreateanaccount.
Inpar-ticular,experimentswhereweactedasthereceivingproviderre-quiredustosendamessagefromaprovidertoourselves,apro-cessthatrequirednon-trivialmanualeffort.
WecallthistheSe-lectproviderlist.
Table2showsthese22providersonorderoftheirpopularityintheleakedAdobeuserlist.
Asdescribedabove,someoftheprovidersservicemultipledomains;suchprovidersareidentiedwiththeirprimarydomainandtheirindicatedpopularityincludesthecontributionofallthedomainstheyservice.
Forex-ample,hotmail.
comincludeslive.
comandoutlook.
com,andyahoo.
comincludesmanyregionalYahoo!
domainsthatareser-vicedbythemainYahoo!
mailservers.
Wenotethatyahoo.
co.
jpandyahoo.
co.
inarenotservedbythesameMTAsasyahoo.
com.
4.
1.
3GeneratorListMuchoftheemailwereceiveinourinboxesisgeneratedauto-matically,includinge-commerceorderconrmations,updatesfromonlinesocialnetworks,andsoon.
WecreatedalistofsuchemailgeneratorsbyattemptingtocreateanaccountwitheachserviceintheAlexaTop100list.
Wesucceededindoingsofor61oftheseservices.
WealsocreatedashortlistoforganizationsorservicesnotontheAlexa100thatwebelievedmightwarrantadditionalemailcondentialityandfromwhichwewereabletogenerateanemailmessage.
WecalltheseservicestheGeneratorlist,showninTable4.
4.
2IncomingMTABehaviorForTLStobeusedonaSMTPhopalongthemessagepath,boththeclientandservermustsupportTLS.
WeinteractedwiththeincomingMTAsofprovidersontheproviderlisttodeterminewhethertheysupportedTLSandwithwhatoptions.
IncomingMTAswereidentiedbyretrievingtheMXrecordsforeachprovider'sdo-mains.
IfadomaindidnothaveanyMXrecords,whichhappenedwith0.
43%ofdomains,weusedthedomainnameitselfasthein-comingMTA,asspeciedinRFC5321.
ForeachincomingMTAthusidentied,theinteractionranasfollows:1.
Connect.
WeresolvedtheSMTPserverhostnametoanIPv4addressandopenedaconnectiononport25.
Theinitialcon-nectionstepfailedfor7.
89%servers.
2.
EHLO.
WeissuedtheEHLOcommandwiththefullyqual-ieddomainname(FQDN)ofourserverperRFC5321.
IftheserverdidnotacknowledgetheEHLOthenwefellbackto4Allmergeswerevalidatedmanually.
theHELOcommandandnotedthattheserverdidnotsupportESMTP.
0.
85%oftheincomingMTAswecontacteddidnotsupportESMTP,accountingfor0.
59%ofalldomainsontheproviderlist.
3.
ESMTPOptions.
UponsuccessfulexecutionoftheEHLOcommand,serversrespondedwithalistofsupportedESMTPoptions.
ForincomingMTAs,44.
98%ofserversinthisstepdidnotadvertisetheSTARTTLSextension(44.
60%ofallservers).
Nevertheless,wedidnoteliminatesuchserversfromconsiderationandattemptedtoissuetheSTARTTLScommandinthenextstepregardlessofadvertisedsupport.
4.
STARTTLS.
WeissuedtheSTARTTLScommandtotheserver.
TheSTARTTLScommandfailedfor0.
51%ofincomingMTAsthatadvertisedtheSTARTTLSoptioninthepreviousstep(45.
31%ofallservers).
OftheserversthatdidnotadvertiseSTARTTLSsupport,0.
30%didrespondtotheSTARTTLSbystartingaTLShandshake.
5.
TLShandshake.
WecarriedouttheTLSnegotiationphaseandrecordedtheoptionssupportedbytheserverandtheservercerticate.
Wedidnotsupplyaclientcerticate.
6.
Mailtransfer.
WithTLSencryptioninplace,weeitherpro-ceededtosendanemailmessage(ifwehadanaccountwiththeserviceasdescribedinSection4.
1.
2)orissuedtheQUITcommand.
4.
3OutgoingMTABehaviorAprovider'soutgoingMTAplaystheroleofaclientwhentrans-ferringmailtoanincomingMTAofanotherprovider.
Inthisrole,itmustissuetheSTARTTLScommandtostarttheTLSsession.
TotestwhichoutgoingMTAsdoso,wegeneratedamessagefromtheproviderinquestiontoanincomingMTAserverwecontrol.
Ofcourse,thisrequiresanaccountattheproviderinquestion,sotherststepinthisexperimentwascreatingtheseaccount.
Inall,wecreatedaccountsat22mailprovidersrepresenting75.
05%ofusersaccordingtotheproviderlistranking.
InteractionwiththeoutgoingMTAproceededasfollows:1.
HELO/EHLO.
TheclientmustrstissueaHELOorEHLOcommandidentifyingitself.
ThelatteridentiestheclientasspeakingESMTP,whichwasthecaseforall22providers.
Weacceptedboth.
2.
ESMTPOptions.
IftheclientusedtheEHLOcommand,weadvertisedtheSTARTTLSextension.
3.
STARTTLS.
AclientwishingtouseTLSwouldnowis-suetheSTARTTLScommand,inordertoprotecttherestoftheSMTPsessionusingTLS.
15ofthe22ESMTP-speakingoutgoingMTAsdidso.
ForMSAs,wealsoattemptedtopro-ceedwithoutissuingSTARTTLStodetermineifaproviderwouldacceptlogincredentialsandmailoveranunsecuredconnection.
4.
TLShandshake.
WecarriedouttheTLShandshake,offer-ingtheclientourservercerticate.
Weuseddifferentcerti-cateseachsessiontodeterminethelevelofcerticatecheck-ingdonebytheclient.
ThecerticatesweusedaredescribedinSection5.
3.
2.
Wealsorequestedaclientcerticate,andrecordeditifitwasprovided.
5.
Mailtransfer.
Weacceptedanymailofferedbytheclient.
4.
4SMTPMSABehaviorToassessthelevelofTLSsupportbySMTPMSAs,weobtainedmailsubmissioncongurationinformationfromthe22providersontheselectproviderlist.
15ofthe22providersinstructedtheusertoconguretheirmailreadertouseTLS.
ForSMTPwithReceived:fromBLU004-OMC4S27.
hotmail.
com(blu004-omc4s27.
hotmail.
com.
[65.
55.
111.
166])bymx.
google.
comwithESMTPSid.
.
.
for(version=TLSv1.
2cipher=ECDHE-RSA-AES128-SHAbits=128/128);Sun,15Feb201516:35:49-0800(PST)Figure2:ExampleReceivedlineaddedbyGoogle'sincomingMTAmx.
google.
comtoamessagefromHotmail,identifyingHotmail'soutgoingMTAblu004-omc4s27.
hotmail.
com,andgivingTLSparameters.
Omittedinformationshownas".
.
.
"STARTTLS,weperformedthesameinteractionasforSMTPin-comingMTAs(Section4.
2),howeverwealsocheckedthattheMSAwouldproceedwithouttheclientissuingSTARTTLSrst.
ForSMTPSMSAs,wecarriedouttheTLShandshakeandcapturedtheservercerticate.
4.
5POPandIMAPBehaviorForthe22providersintheselectproviderlist,wecontactedeachprovider'sPOPandIMAPserver.
All22offeredPOPandIMAPsupport,15ofthe22providersinstructedtheusertocon-guretheirmailreadertouseTLS.
Ourinteractionranalongsim-ilarlinesasSMTPMSA.
ForPOP3andIMAP,wecarriedoutthehandshakeandcapturedthecerticate.
ForthePOP3andIMAPwithSTARTTLS,werecordedwhethertheSTARTTLSoptionwasadvertised,issuedSTARTTLSand,andcapturedthecerticate.
Wedidnotuseaclientcerticate.
4.
6WebmailBehaviorUsersmayalsointeractwiththeiremailproviderusingaWebin-terface.
Allofthe22providersinourselectprovidersetsupportedthisoption.
Foreach,werecordedwhethertheWebmailinterfacesupportedHTTPS,whetherornotitwasthedefault,andwhetherthecerticatewasvalid.
4.
7ReportedTLSUseTheSMTPstandardrequiresmailserversalongamessagepathtoprependaReceivedheaderline,indicatingwhen,bywhichserver,andfromwhichserver,amessagewasreceived(Sec.
4.
4,RFC5321).
ThestandardalsodenesadditionalinformationwhichaservermayaddtotheReceivedline,includingprotocolinfor-mationintroducedbytheWITHkeyword.
RFC5321denestwopossiblevalues,SMTPandESMTP,indicatingwhetherESMTPwasusedornot.
RFC3848extendsthislisttoincludeothers,includ-ingESMTPS,whichindicatesthatTLSwasused.
Figure2showsasampleReceivedline.
WeusedthisfeaturetomapTLSuseontheinternalhops(b)and(d).
Wesentmessagesfromouraccountoneachprovidertoourserverandfromourservertoanaccountateachprovider,andcollectedtheReceivedheadersfromthesemessages.
Wethenex-tractedtheWITHclause,ifpresent,ofeachline,usingittoinferTLSuse.
4.
8Cross-ProviderValidationRecallthatourmessagepathmeasurementtechniqueisbuiltonthepremisethatTLSusebetweenaclientandaservercanbein-ferredfromtheirbehaviorwheninteractingwithus.
Todetermineifthisisindeedthecase,wesentmessagesbetweenallpairsofprovidersontheselectproviderlist(484messagesinall).
WethenusedtheReceivedheaderinformationdescribedabovetodeter-mineifprovidersexhibiteddifferentpairwisebehaviorthanmightbeexpectedfromtheirinteractionwithus.
ResultsareshowninTable6anddiscussedinSection5.
3.
4.
9CerticatesWhentestingservercerticates,wecheckedifthecerticatewasrevoked(viaaCRL)orexpired.
Wecheckedifthecerticatecom-monnameoranyofthesubjectAltNamematchedthehostnametowhichwewereconnecting.
WealsocheckedifthecerticatewassignedbyatrustedCAusingtheMozillalistasthetrustedroot.
5Wealsonotedthesignaturealgorithmused.
4.
10DKIMTodetermineDKIMsigningbyoutgoingmailproviders,weex-aminedthemessagesusedintheoutgoingMTAmeasurement(Sec-tion4.
3)todetermineifaDKIMsignatureispresent,andifso,ifthesignatureiscorrect.
SincethismeasurementrequiredhavingaDKIMselectorfromasignedmessage,wecouldonlyperformthismeasurementforprovidersontheselectproviderlist,fromwhomwereceivedemail.
Foreachmessageexamined,weextractedtheDKIM-Signatureheaderfromthemessage,retrievedtheDKIMkey(ifoneexists)fortheselector.
_domainkey.
domain.
comTXTrecordwhereselectoranddomain.
comaretheselectoranddomainfromtheDKIMheader.
ThehashfromtheDKIMSigna-turewasthendecryptedwiththeDKIMkey.
IfthedecryptedhashmatchesthecomputedhashofthemessagethentheDKIMsigna-tureismarkedasvalid.
ToevaluatetheeffectofDKIMuseonincomingmail,wegen-eratedmailtoprovidersontheselectproviderlist.
Wesentthreekindsofmessagestoeach:withoutaDKIMsignature,withavalidDKIMsignature,andwithaninvalidDKIMsignature.
Thesubjectandbodyofthethreemessageswereidentical;however,thedate,includedinthesignature,varied.
EachtypeoftestwasconductedfromadifferentIPaddresstoavoidIPreputationbias.
Wethenexaminedwhetherthemessagewasrejected,markedasspam,ordeliveredtotheuserinboxofouraccount.
Inaddi-tiontodeterminingmessageoutcome,wealsorecordedwhethertheproviderqueriedourDNSserverforTXTrecordcontainingtheDKIMsigningkey.
Theselectorwasnotpreviouslyusedtoensuretherecordwouldnotbecached.
4.
11SPF,ADSP,DMARC,andDNSSECTotestprovidersupportforSPFandDMARCinoutgoingmail,wequeriedthenameserverofprovidersontheproviderlistfortheDNSTXTrecordusedbyeachprotocol.
Inaddition,wemadenoteofwhethertheprovider'smailserversupportedDNSSECandreturnedsignedrecords.
DNSSECwasveriedbyqueryingeachdomainsDNSKEYrecord.
IfnoDNSKEYrecordwasfound,thenthedomainwasmarkedasnotsupportingDNSSEC.
IftherewasaDNSKEY,thenwequeriedtwoDNSservers,onewithoutDNSSECsupport,andoneenforcingDNSSECfortheArecordofthedomain.
IftheDNSSECenabledserverrespondedwithoutaSERVFAILresultthenDNSSECpassed,otherwisethedomainhadinvalidDNSSEC.
TheDNSserverwith-outDNSSECwasusedasacontroltoensurethatthereexistsDNSrecordsforthedomain.
SPFvalidationwastestedbysettingtheSPFTXTrecordforourtestdomainto"v=spf1a-all"whichshouldfailorrejectmailnotsentfromourdomain'sArecord.
WethensentmessagestothetopmailprovidersfromanIPaddressnotinourdomain'sDNS.
WerecordedwhethertheSMTPsessiontotheprovider'sMTAwassuccessful,andifitwas,ifthemessagesentendedupintherecip-ient'sinboxorspamfolder.
TotestDMARCwesettheDMARCTXTrecordforadomainunderourcontrolto"v=DMARC1p=reject".
Wethenrepeated5https://wiki.
mozilla.
org/CA:IncludedCAsSMTPPOP3IMAPHTTPOutInhotmail.
comgmail.
comyahoo.
com····aol.
comgmx.
demail.
ruyahoo.
co.
incomcast.
net·web.
deqq.
comyahoo.
co.
jp····naver.
com·163.
comtwc.
comlibero.
it·yandex.
rudaum.
netcox.
netatt.
net····wp.
pl·pacbell.
net····sohu.
comTable3:TLSbehaviorofuser-facingSMTP,POP3,IMAP,andHTTPserversoftopmailproviders(leftframe)andtheinternalstructureofeach(rightframe).
Legend:validcerticatewithmatchinghostname,validcerticatewithdifferenthostname,noTLSsupport;theproviderrejectednon-TLSconnections.
Intherightframe,theOutcolumnshowsMSAtooutgoingMTAmessagepath;theIncol-umnshowstheincomingMTAtoMDApath.
Eachsymbolindicatesaninternalhop.
Legend:TLSwasused,noTLSused,·anunknownprotocolwasused.
sendingmailwithaninvalidDKIMsignatureasdescribedinSec-tion4.
10.
SettingthepolicytorejectshouldresultinmailbeingcanceledattheSMTPlayeriftheDKIMsignatureisnotcorrect.
WerecordediftheSMTPconnectiontotheprovider'sMTAwassuccessful,andifso,whetherthemessagesentendedupinthere-cipient'sinboxorspamfolder.
Asacontrolwealsotestedwiththepolicysetto"p=none".
TotestwhetherprovidersusedSPF,ADSPandDMARCinpro-cessingincomingmail,wesentmailtoeachoftheprovidersontheselectproviderlist.
Foreach,wesentamessagebothfromanIPaddressnotauthorizedtosendemailperSPFpolicy,andonefromwhichemailwasauthorized.
AsintheDKIMexperiment,wethenexaminedwhetherthemessagewasrejected,markedasspam,ordeliveredtotheinbox.
WealsorecordedwhetherthereceivingproviderqueriedourDNSserverfortheDKIM,SPF,ADSP,orDMARCTXTrecords.
5.
RESULTSRecallthatwesetouttodeterminewhetheragivenmessagepathissecuredwithTLSalongeachhop.
InSection4wedescribedhowwecaninferTLSusealongthepathfromdirectandindirectinteractionwiththeservers.
Herewepresentourndings.
5.
1SubmissionandDeliveryTherstandlasthopinamessagepath,labeled(a)and(e)inFigure1,involvetheuser.
ThesecurityofthesetwohopsdependsontheuserMUAandontheMSAandMDAoftheprovider.
5.
1.
1SMTP,POP,andIMAPWetestedtheSMTP,IMAPandPOPserversspeciedbyeachprovider(ofthe22selectproviders)intheirmailclientcongura-tioninstructions.
OurresultsareshowninTable3,wherede-notesnoTLSsupport,andallothermarksindicateTLSwassup-ported.
Onlyoneprovider,sohu.
com,didnotprovideTLSsupportforsubmissionordelivery.
Oneprovider,naver.
comdidnotsup-portPOP3withTLS,butdidsupportIMAPwithTLS.
Oneprovider,twc.
com,supportedTLS,butthecongurationin-structionsprovidedtotheirusersdidnotindicatethatTLSshouldbeenabled,leavingituptotheMUAtoissuetheSTARTTLScom-mand.
SomeprovidersrequiredTLSuse,andwouldnotserveaclientwithoutTLS.
TheseprovidersareshowninTable3withamark.
Thetopthreeproviders—Hotmail,GMail,andYahoo!
—allrequireTLSformailsubmissionanddelivery.
Certicates.
Table3alsoindicatesthetypeofTLScerticatepre-sentedbytheMSAorMDA.
Themarkindicatesthatacer-ticatewasnotrevoked,expired,orsignedbyanuntrustedCA(Sec.
4.
9).
Allcerticatesweencounteredheremetsatisedtheseconditions.
Wealsocheckedwhetherthecerticatenamematchedthenameofthehosttowhichwemadetheconnection.
Herethesituationwaslessrosy.
ForMSAs,of6ofthe22providersusedaservercerticatethatdidnotmatchtheserverhostnametowhichwewereconnecting.
(Recallthattheservernamewasobtainedfromtheprovider'sowncongurationinformation.
)Hotmail,forexample,speciesthatsmtp-mail.
outlook.
comshouldbeusedformailsubmission,howeverthecerticateofferedbythisserverhasthecommonname*.
hotmail.
comandnosubjectAltName.
Onthedeliveryside,wefoundthatanumberofproviders,includ-ingHotmailandYahoo!
,sentmismatchedcerticates.
5.
1.
2WebinterfaceAllofthe22selectprovidersofferedaWebmailinterface,how-ever,three(163.
com,libero.
it,anddaum.
net)didnotofferTLSsupport.
Amongthetop10providers,allexceptqq.
comandcomcast.
netrequiredSSL/TLStoaccessWebmail.
Certicates.
AllcerticatesusedforHTTPSwerematchingandvalid.
Thisisnotsurprising,giventheintimidatingwarningsis-suedbymodernbrowsersformismatchedcerticates.
Thefail-uretocheckformatchingcerticatesbyMUAslikelyexplainsthelargenumberofmismatchedcerticatesusedbyMSAsandMDAs.
5.
2InsidetheProviderOncesubmittedtoamailprovider,amessagemaytransitanum-berofinternalserversbeforereachingtheoutgoingMTA.
Wedonothavevisibilityintointernalmessageprocessing,soourmea-surementsarebasedoninformationgivenintheReceivedheaders(Section4.
7).
Usingthese,wereconstructedtheuseofTLSinsidethe22selectprovidersontheoutgoingandincomingpath(labeled(b)and(d)inFigure1).
Table3showsourresults.
TheOutgoingcolumnshowsinter-nalhopsontheoutgoing(MSAtooutgoingMTA)pathandtheIncomingcolumnshowsinternalhopsontheincoming(incomingMTAtoMDA)path.
Eachmarkrepresentsahop:indicatesTLSwasused,indicatesTLSwasnotused,and·indicatesthatanon-standardprotocolwasused.
Yahoo!
appearstouseaprotocolcalledNNFMPinternally.
Itisnotpubliclydocumented,andwedonotknowifitusesTLS.
Someprovidershadmultipleroutesamessagecouldtake,inthiscasewefavoredtheroutewiththemosthops.
Overall,TLSuseoninternalhopsisnotwidespread.
(Weempha-sizethatinternalhopsmaybeonthesamelocalnetwork,ormaybecarriedonaninter-datacenterVPN.
)Incomingmessagepathsaremuchshorter,andinsomecases,recordnohopsatall.
NoneoftheincomingmessagepathsappearedtouseTLS.
ProviderswhichreportnohopsfromtheMTAtoMDAsuchasweb.
demaybeusingthesamehostforboththeMTAandMSA,ormaynotberecordingtheinternalhopstothemessageheaders.
5.
3Provider-to-ProviderThehopbetweenproviders,fromoutgoingtoincomingMTA,usesSMTP.
Intheabsenceofprovider-to-providerpeering,mes-sagesalongthishopwilltransitthepublicInternet.
Itisperhapsherethattheriskofmasstrafcinterceptionisgreatest.
Asdis-cussedinSections4.
2and4.
3,weusethebehavioroftheoutgoingandincomingMTAswhencommunicatingwithustoinferhowtheymightbehavewhencommunicatingwitheachother.
Becauseofthemanualeffortrequired,weevaluatedoutgoingMTAbehav-iorforselectprovidersonly.
ForincomingMTAs,weusedthetop1milliondomainsrepresenting245,054distinctprovidersin2015(266,323in2014).
Wethencombinethesetoformapictureofmes-sagepathsbetweenselectprovidersandthefullsetofproviders.
5.
3.
1TLSSupportatOutgoingMTAsEmailproviders.
TherstcolumninTable6,labeledCONTROL,showstheuseoftheSTARTTLScommandbyprovideroutgoingMTAswhencontactingourserver.
Theverticalheadersaretherstcharacterofthesendingprovider.
ThemarkindicatesTLSwasnotused,indicatesthatTLSwasusedinbothscans(March2014andFebruary2015),and%indicatesthatTLSwasusedintheFebruary2015scanbutnotintheMarch2014scan.
(TherewerenocasesofTLSbeingusedin2014butnot2015amongtheselectproviders.
)Thetop10providersallusedTLSwhenofferedin2015.
Othergenerators.
WealsoexaminedoutgoingMTATLSsupportofmajorWebservices(Section4.
1.
3)inMarch2014.
TheseresultsareshowninTable4,groupedbycategory.
NotethatsomenamesappearinTable6andTable4withadifferentlevelofTLSsupportindicated.
Theseareservicesofferbothmailandnon-mailservices.
Table6showsTLSsupportforoutgoingMTAsusedbythemailservice,whileTable4showsTLSsupportforoutgoingMTAsusedbythesite'suseraccountsystem.
Forexample,yandex.
ruisbothamailproviderandapopularWebportal.
Registeringanemailaccount(notnecessarilya@yandex.
ruaccount)withthesitewillgenerateemailrelayedbyanoutboundMTAthatdoesnotuseTLS.
SupportforTLSonoutgoingMTAlinkswashighestamongthenancialinstitutionsweexamined.
AllbutUSBank'soutgo-ingMTAsupportedTLS.
Thelowestlevelofsupportwasamongnewsanddatingsites.
Thelatter,inparticular,issurprising,giventhepersonalnatureoftheemails.
5.
3.
2CerticateCheckingatOutgoingMTAsAsdescribedinSection4,weperformedtheexperimentsev-eraltimes,offeringdifferentcerticatestotheoutgoingMTAeachtimeitconnected.
Wefoundthatallbutthreeproviders,wp.
pl,comcast.
net,andhotmail.
com,didnotperformanycerticatechecking.
(Forspacereasons,resultsarenotpresentedintabularform.
)Inparticular,allbutthosethreeacceptedarevoked,ex-pired,self-signed,mismatchedcerticatewithaweaksignature(sha1WithRSA512bit).
TheoutgoingMTAsforhotmail.
com,wp.
pl,andcomcast.
netrejectedourcerticateonlybecauseitwasexpired.
Remedyingthis,theiroutgoingMTAsacceptedtherevoked,self-signed,mismatched,weakcerticate.
5.
3.
3OutgoingMTAClientCerticatesForeachconnectionfromanoutgoingMTA,wealsorecordedtheclientcerticateprovidedbytheMTAduringTLSnegotia-tion.
(Ourserverwasconguredtorequestit.
)7ofthe22selectDomainTLSSPFDMDomainTLSSPFDMSearchCommercegoogle.
comamazon.
comyahoo.
comebay.
combaidu.
comadcash.
comqq.
comneobux.
comlive.
comgodaddy.
comhao123.
comcraigslist.
orgsohu.
comaliexpress.
comyandex.
rualibaba.
combing.
comalipay.
com163.
comrakuten.
co.
jpmail.
ruMiscEntertainmentask.
comyoutube.
com360.
cnxvideos.
commicrosoft.
comimgur.
comthepiratebay.
sexhamster.
comkickass.
tovube.
comimdb.
comyouku.
comstackoverow.
compornhub.
comwikipedia.
orgvimeo.
comdailymotion.
comBanksnetix.
combankofamerica.
compaypal.
comGovernmentchase.
comhealthcare.
govdiscover.
comwhitehouse.
govusbank.
comamericanexpress.
comConferenceseasychair.
orgSocialhotcrp.
comwordpress.
orgfacebook.
comNewslinkedin.
comsina.
com.
cntwitter.
commsn.
comblogspot.
comcnn.
comweibo.
compeople.
com.
cnwordpress.
comgmw.
cnvk.
comespn.
go.
compinterest.
cominstagram.
comDatingtumblr.
commatch.
comreddit.
comzoosk.
comfc2.
comokcupid.
comblogger.
compof.
comodnoklassniki.
ruTable4:TLS,SPF,andDMARC(DM)supportamongoutgoingMTAsusedbyselectWebservicestosendemail.
indicatesnosupportorprotection,indicatesbasicsupport,andindicatesthatSPForDMARCisconguredinastrictmanner.
providersreturnedaclientcerticateforourrequest.
Ofthese,onlyone,fromcomcast.
com,wasexpiredorotherwiseinvalid.
5.
3.
4TLSSupportatIncomingMTAsSelectproviders.
ThetoprowinTable6,labeledCONTROL,showssupportforTLSattheincomingMTAforthe22selectproviders.
ItissurprisingtoseethatmoreproviderssupportsendingwithTLSthanreceivingwithTLS.
HoweverGoogle'sTLSdatadiscussedinmoredetailinSection6showsthat7oftheprovidersweobservednotsendingwithTLSdouseTLSwithGoogle.
Otherproviders.
AsdescribedinSection4.
2,wealsotestedtheincomingMTAsoftheprovidersforthetop1milliondomainsintheAdobeleak.
Amongthese302,938MTAs(covering245,054providers),50.
5%supportedTLSinMarch2014,increasingto54.
6%inFebruary2015.
Amongthetop1000providers,supportforTLSincreasedfrom43.
7%to59.
2%.
StatusFreq.
2014Freq.
2015Valid75.
86%79.
14%SelfSigned20.
47%11.
39%Expired3.
41%2.
88%Revoked0.
17%0.
04%NonMatched34.
13%37.
26%Table5:CerticatestatusofthetopmailreceivingMTAsfoundintheAdobedataset.
ReceivingProviderCONTROLhotmail.
comgmail.
comyahoo.
comaol.
comgmx.
demail.
ruyahoo.
co.
incomcast.
netweb.
deqq.
comyahoo.
co.
jpnaver.
com163.
comtwc.
comlibero.
ityandex.
rudaum.
netcox.
netatt.
netwp.
plpacbell.
netsohu.
comC%hgy-ag-mycw-qy-n%1%t-l---yd--caw%-p%%sTable6:Pairwisebehavioroftopmailproviders.
Eachrowislabeledwiththerstcharacteroftheprovider'sname.
indicatesTLSsupport,%indicatesTLSsupportwasaddedwithinthepastyear,indicatesthatthemessagewassentwithnoTLSwhatsoever,meansthattheMTAlinkdidnotrecordanyinformationaboutthepro-tocoloruseofTLS,and-meansthatthemessagedidnotgothrough.
Thetop10providerscover70%oftheusersintheleakedAdobeuserlist.
Giventhatallofthetop10providerssupportedTLSattheincomingMTA,itisworthrecastingtheabovenumbersintermsofusers.
Whenweightedbythenumberofusers,TLSsupportin-creasedfrom52%ofusers(top1milliondomainsonly)in2014to89%in2015,asubstantialimprovementlargelyduetoHotmail'sadoptionTLSatincomingMTAs.
5.
3.
5IncomingMTAServerCerticatesOfthe10selectprovidersthatusedTLS,theincomingMTAsof3usedmismatchedbutotherwisevalidcerticates.
Beyondtheseproviders,however,thecerticatesproducedbytheincomingMTAsrangedwildlyinquality.
Table5summarizesourndings.
Wearepleasedtoseethatinthepastyearthepercentageofvalidcerti-cateshasrisen,andselfsigned,expiredandrevokedcerticateshasfallen.
CerticatesthatdidnotmatchthehostnameoftheincomingMTAdidrise,whichweattributetotheoverallincreaseinTLSuse,andthereductionofotherwiseinvalidcerticatesthatwouldhavepreviouslybeeninanothercategory.
5.
3.
6PairwiseTLSSupportThepremiseofourlarge-scaleanalysisisthatknowingoutgo-ingandincomingMTAbehaviorallowsustoinferhowthetwowouldbehavetalkingtoeachother.
Tovalidatethis,wesentemailbetweenthe22selectproviders.
Table6showstheresultsofthisexperiment.
EachelementofthetableshowswhetherTLSwasDNSSECSPFDKIMDMARCSPFDKIMDMARCSPFDKIMDMARCDomainImplementationDNSLookupEnforcementhotmail.
comgmail.
comyahoo.
comaol.
comgmx.
demail.
ruyahoo.
co.
incomcast.
netweb.
deqq.
comyahoo.
co.
jpnaver.
com163.
comtwc.
comlibero.
ityandex.
rudaum.
netcox.
netatt.
netwp.
plpacbell.
netsohu.
comTable7:DNSmechanismcongurationandbehaviorofthetopmailproviders.
Im-plementationindicateswhethertheproviderhasthecorrectDNSrecordsforverifyingmessagestheysend.
DNSLookupshowswhethertheproviderqueriedourDNSserverfortheselectorforeachfeaturewhensendingmail.
EnforcementindicateswhethertheprovidertakesanyactionwhenreceivingamessagefromahostthatSPFforbids,aninvalidDKIMsignature,orrejectingDMARCrecords.
indicatesnosupport,indicatessupport,indicatesastrictDKIMpolicyof"reject"andindicatesthattheprovidertookactiononmailsentfromahostnotlistedintheSPFrecord.
usedontheinter-providerhop,basedonReceivedheaderdata.
Forexample,amessagefromGMailtoHotmailwastransferredfromGMailtoHotmailoveraTLS-securedsession,representedbythe%markintherstrowlabeledg(forgmail.
com)andcolumnlabeledhotmail.
com.
Anumberofentriesareabsent(shownas"-").
Thesecasesoc-curredwhenwecouldnotsendamessagefromoneprovidertoanother.
Wehadparticulartroublesendinggettingemailfromoursohu.
comaccountaccepted.
Itturnedoutthatthesohu.
comSMTPsubmissionserversdidnotrequireausertoauthenticate,allow-ingspammerstousetheirSMTPMSAasanopenproxy.
Entriesmarked""arecaseswhereReceivedheaderanalysisdidnotpro-videaconclusiveindicationonewayoranother.
Thishappenedwithoneprovider,Hotmail,whichusedaprotocolofSMTPSVC,thatwasusedforbothTLSandnon-TLSconnections.
Severalabnormalitieswereobservedinthe2014measurementwhereboththesendingproviderandthereceivingprovidersup-portedTLSbutTLSwasnotused.
Forexampleyahoo.
co.
insendingtoaol.
com.
Weareunabletoobservetheconnectionbe-tweenthetwoproviderstoknowwhatcausedthisbehavior,butitispossiblethatthetwoproviderswhereusingincompatibleTLSciphers,orwheremiscongured.
Howeverallwereresolvedwhenperformingthe2015measurement.
Therewasonlyoneabnormalresultobservedinthe2015study.
Amessagefrom163.
comwastransferredtogmail.
comusingTLS,eventhoughthe163.
comoutgoingMTAdidnotissuetheSTARTTLScommandwhensendmailtoourserver.
5.
4SPFandDKIMAscanoftheAlexaandAdobetopmilliondomainsshowsusthatjustover40%haveavalidSPFrecord,whichcovers85.
02%MetricAlexaHostsAdobeHostsAdobeUsersDNSSEC3.
40%2.
75%4.
92%Valid2.
96%2.
12%1.
35%Invalid0.
44%0.
63%3.
57%DMARC0.
97%0.
90%67.
81%None0.
73%0.
66%51.
29%Quarantine0.
08%0.
06%0.
46%Reject0.
16%0.
18%16.
06%SPF42.
26%43.
60%85.
02%Table8:DNSSEC,DMARCandSPFstatusoftheAlexaandAdobetopmillionhosts.
ofAdobeusers(Table8).
IntheSPFImplementationcolumnofTable7,andtheSPFcolumninTable4,wedisplayaifSPFisimplemented,andaifthepolicyisstrict.
WedeneastrictpolicyforSPFasendingin"-all",whichinstructsthereceivertorejectmailnotfromthecorrectorigin.
15ofthe22mailprovidershaveSPF,butonly5implementastrictpolicy.
SPFuseishighwithmostpopularwebservices,exceptnewssites,andisoftenstrict.
TheDNSLookupcolumnsofTable7showaiftheprovidermadethenecessaryDNSquerytolookuptheSPForDKIMrecord.
TheEnforcementcolumnsshowsaifinvalidSPForDKIMre-sultedinthemessagebeingplacedintheusers'sspamfolder.
AindicatesthatthereceivingMTArejectedthemessageattheSMTPlayer.
AlmostallprovidersperformedtheSPFDNSquery,butonly10tookaction,halfattheSMTPlayer.
11oftheprovidersperformedtheDKIMselectorlookup,butonly3markedthemes-sageasspam.
EveryDKIMmessagewithaninvalidsignaturewasallowedtosuccessfullycompleteSMTPdeliverytotheMTA.
5.
5DNSSEC,DMARC,andADSPOfthetopmailprovidersonlycomcast.
netsupportsDNSSEC.
About3%oftheAlexaandAdobetopmillionhaveDNSSEC,how-ever13%ofAlexaand23%ofAdobehostswithDNSSECfailverication.
WenotethattherearemoreAdobeuserswhohavein-validDNSSECthatvalid,whichiscausedbypopularprovidersintheAdobelisthavingimproperDNSSECconguration.
ForDMARCentriesintheImplementationcolumnofTable7andinTable4,wedisplayaifDMARCisimplemented,andaifimplementingastrictpolicy.
ADMARCpolicyisstrictifitspolicyistorejectinvalidmessagesbysetting"p=reject".
DMARCisimplementedbyabouthalfofthewebservicesandtopmailproviders,includingallthebanks,andallbut1ofthecom-mercesites.
AbouthalfofthewebserviceswithDMARChaveastrictpolicy,mostofwhicharebanksorsocialsites.
Only2mailprovidershadastrictpolicy.
Whenreceivingmail,9ofthetopprovidersperformedaDMARClookup,and7tookaction.
2providerslteredmessageswithastrictDMARCpolicywithoutdoingtheDNSlookupswhichweattributetotheprovidertakingactionontheDKIMsignaturefailingbeforetheDMARCcheckisdone.
TheonlyprovidertoqueryforanADSPrecordwas163.
com.
WhileSPF,DKIM,andDMARCarewidelyimplemented,wefoundthatSPFoffersthestrongestauthenticityprotectionandim-pactondeliverability.
Wealsonotethatemailgeneratedbythepa-persubmissionsystemofthisconferencewassenttousbyaMTAthatsupportsTLS,SPFandDMARC.
(Acompetingconferencemanagementsystem,easychair.
orgonlysupportsTLS.
)6.
RELATEDWORKTwopriorindustrystudieshavereportedontheuseofTLSbyMTAs.
FacebookandGooglereleasedreportsofobservedSMTPTLSdeploymentasseenbytheirservers.
Theirresultsprovideafaithfulandvaluablepictureofserverbehaviorfromtheirvantagepoint.
Inthissectionwecomparetheirresultstooursandfoundagreementoncommonmeasurements.
OurworkprovidesamorecompleteviewofTLSdeployment,coveringallpartsofthemes-sagepath.
Ofcourse,wealsoexaminedDKIM,SPF,DMARC,andDNSSEC,whichprovidemailauthenticityandintegrity.
6.
1FacebookStudyIn2014FacebookreportedTLSusewhensendingnoticationemailstotheirusersforaday[2].
Theyreported76%ofincom-ingMTAsforuniqueMXrecordsofferedSTARTTLSwhensendingemailstotheirusers,andabouthalfofthecerticatespassvalida-tion.
58%ofFacebook'soutgoingnoticationemailusedTLS.
Wefound54%ofouruniqueMXrecordsfromhostsintheAdobelistallowTLSforreceivingmail,whichislowerthanFace-book'sndings.
Howeverwend52%ofusersin2014,andin89%2015canreceiveTLSmessageswhenrankedbytheAdobelist.
Wealsoobservedmuchhighercerticatevalidation,75.
85%in2015and79.
14%in2015.
6.
2GoogleStudyGoogleoffersSTARTTLSdataonanongoingbasisaspartoftheGoogleTransparencyReport.
6Googlereports46%ofoutboundand40%ofinboundmessagesusedTLSatthetimeofoursecondmeasurement(February2015).
NotethattheGooglereportmea-suresnumberofmessagestransportedusingTLSontheMTA–MTAlink.
TheclosestpointofcomparisonisourestimateofthenumberofprovidersweightedbytheirfrequencyintheAdoblelist(Sec.
5.
3.
4):52%inMarch2014and89%inFebruary2015.
Morerecently,Durumericetal.
[3]carriedoutaconcurrentstudysimilartoours,evaluatingSTARTLS,DKIM,andSPFdeploymentasseenfromGoogle.
TheirmeasurementswerecarriedoutinApril2015.
DuringthisperiodtheyreportedTLSusefor80%ofin-comingconnections,whileweestimatethat89%ofprovidersintheAdobelist,weightedbynumberofusers,asdescribedabove.
Durumericetal.
reportthat74%ofincomingmailatGMaildoesnothaveaDMARCpolicy.
Wefoundthat32%ofprovidersintheAdobelist,weightedbyfrequencyofoccurrence,didnotpublishaDMARCpolicy.
Thedifferenceissignicant,andmostlikelyduetothedifferentmixofprovidersinthetwomeasurementsets.
Theauthorsalsoreportthat92%ofmailarrivingatGooglehadanSPFrecordforthesender.
Wefoundthat85%ofprovidersintheAdobelist,weightedbyfrequencyofoccurrence,hadSPFrecords.
Inadditiontoreportingprotocolusestatistics,Durumericetal.
ndevidenceofTLSstrippingattacks—man-in-the-middleattackspreventingaTLSconnectionfrombeingestablished,forcingthemailtransfertotakeplaceintheclear.
Theyreportthatupto20%ofemailreceivedbyGoogle'sincomingMTAsfromcertaincountriesshowedevidenceofTLSstripping.
7.
DISCUSSIONInthissectionweconsidertheimplicationsofourresultsinthepresenceofeachofthethreetypesofattackerweconsidered.
7.
1PassiveEavesdroppingAttacksApassiveattackercanobservenetworktrafcbutcannotblockormodifyit.
Toprotectagainstsuchanattacker,itissufcienttoestablishasharedsecretbetweensenderandreceiver.
Thisisef-fectivelywhatSSLwithoutcerticatecheckingenables,providedotherrequirementsoftheprotocolaremet.
Weconsiderabestcaseandaworstcasescenario.
Bybestcase,wemeanascenariowhere6https://www.
google.
com/transparencyreport/themostsecureoptionischosen,ifpossible.
Inparticular,weas-sumeemailissubmittedanddeliveredusingthemostsecuremeans,andthatinternallinksaresecure.
Byworstcase,wemeanthattheleastsecureoptionischosen:submissionanddeliverywillusetheleastsecuremeans.
Bestcase.
Allofthe22selectprovidersweconsideredprovideatleastonemeansofsubmittingandretrievingemailoverasecureconnection,and17ofthe22useTLSonallmeansofsubmissionanddelivery.
Ontheinternalhops,wefoundthatfewprovidersuseTLSinternally.
Nonetheless,internalhopsmaybesecuredbyothermeans,soforthebestcasescenario,weassumethatthisisthecase.
Thusfar,then,usersubmission,delivery,andprovider-internaltransportaresecure.
OntheMTA–MTAlink,however,TLSisnotaswidelydeployed.
Only135(about28%)ofthe484ofthepairsofconnectionsbetweenthe22selectproviderswoulduseTLS.
Thatamountstoabout50%ofthemessagetrafc,whenweightedbynumberofusers.
Ifweextendthistomessagesbe-tweenselectprovidersandallproviders,theproportionofTLS-protectedmessages74%.
Worstcase.
Fortheworst-casescenario,weassumeauserchoosestheleastsecuresubmissionanddeliverymechanismavailableateachprovider.
Infact,theprovidersthatallowinsecuremailsub-mission(Table3)arethesameonesthatdonotsupportTLSattheoutgoingMTA,andsimilarlyforthedeliveryside.
Thus,whileourworstcasescenarioincreasestherisk,thenumberofmessagestransferredoversecuredlinksdoesnotdecrease.
Ifwedonotassumethatinternallinksaresecure,thentheonlyprotectionagainsteavesdroppingbyapassiveattackerisprovidedbySTARTTLS,thenanyinternalhopsnotusingTLSmaybetar-getedbyanattack.
Oftheselectproviders,onlyfour,aol.
com,hotmail.
com,web.
de,andqq.
com,useTLSonallinternalhopsinoutgoingmail.
Thesefourtogethercoverabout34%oftheusersintheselectproviderset.
Ifweconsiderallinternalhopsonthereceivinganddeliverypathtobenolesssecurethantheincom-ingMTAofaprovider,then24%ofmessagessentfromselectproviderstoallproviderswouldtravelalongaTLS-securedmailpath.
Thus,anywherefrom24%to74%ofmessagesfromaselectprovidertoaprovideronthefulllistwouldbeprotectedagainstapassiveattackeralongtheentiremessagepath.
Theformergureisifweallowinltrationofinternallinks,butnoadditionalexposureintroducedonthedelivery,thelatter,iftheonlyexposureisontheMTA–MTAhop.
Weconsiderthisanoverallsuccess,inviewofthefactthatitwasachievedatnocosttotheuser.
7.
2PeerForgeryAttacksOurresultsshowthatsomeproviderswillhonorasender'sstrict"-all"SPFpolicy,andsomeoftheprovidersandemailgenera-torsdidhaveafail-closedpolicy.
Withsomeexceptions,itisgen-erallypossibleforapeerattackertoimpersonateanemailgenera-tororprovidertoanotherprovider.
AdomainownerpublishingastrictSPFpolicycanbeassuredthatsomeproviderswillnotacceptforgedemailfromherdomain.
DKIMuseandenforcementislesswidespread.
Ofthetopveproviders,onlyGMailandYahoo!
usedDKIM,andonlyHotmailmarkedamessagewithinvalidDKIMsignatureasspam.
Howeverpublishingastrict"p=reject"DMARCpolicyresultedinanin-validmessagebeingrejected.
OnlyYahoo!
andAOLhavesuchastrictpolicy,sowecanonlysaywithcondencethatimpersonat-ingthosetwosenderstoHotmail,GMailandYahoo!
,aswellasahandfulofotherprovidersisnotpossible.
Adomainownerpub-lishingastrictDMARCpolicycanbeassuredthatatleastthetopthreeaswellasafewotherswillhonorthepolicy.
7.
3ActiveEavesdroppingAttacksAnactiveattackerhasfullman-in-the-middlecapability.
Topro-tectagainstsuchanattackrequirespropercerticatechecking.
Un-fortunately,wefoundthatthereisnocerticatecheckingonthesubmissionanddeliverypathexceptwhenusingaWebmailinter-face,andnocerticatecheckingatallontheMTA–MTAhop.
EvenapairofusersaccessingmailexclusivelyviaaWebbrowserwouldstillbevulnerabletoanactiveattackerontheMTA–MTAhop.
Aman-in-the-middleattackdoesnotrequirephysicallycuttingintoalink.
BGPandDNShijackingattackswouldallowanattackertoredirecttrafctohimselfduringacriticalperiod.
BGPsecurityisstillinstandardization[5].
WhileDNSSECisavailable,ofthetop10providers,onlycomcast.
nethasaDNSSECsignedMXrecord.
(Howeverthecomcast.
netincomingMTAdidnotsupportTLS.
)7.
4ActiveTamperingAttacksAsnotedearlier,theonlydefenseagainstanactiveattackerisDKIMwithDNSSECandastrictDMARCpolicy(orabilateralagreementtoverifyDKIMsignatures).
Onlyoneprovider,Com-castsupportsDNSSEC.
Andoftheselectproviders14performedsomesortofverication,howeveronly5actuallyenforcedthepol-icy.
GiventhelowratesofDNSSECadoption,thelargerelativenumberofinvalidDNSSECrecords(Table8),andunenforcedSPFandDMARCpolicies,weconcludethatactiveattacksonmessageintegritywillbeunimpeded.
7.
5RecommendationsOurndingsshowthattheInternetmailsystemispartiallyvul-nerabletopassiveeavesdroppingattacksandpeerforgeryattacks,andhighlyvulnerabletoactiveattacks.
Fortunately,asdiscussedearlier,itispossibletoprotectagainstevenanactivenetworkat-tacker.
Thefollowingrecommendationssummarizestepssufcienttoachievethislevelofsecurityusingcurrently-availableprotocols.
Recommendation1:UseTLS.
TLSsupportinSMTP,IMAP,andPOP3isstableandmature.
Allbutoneofthe22providersupportsTLSforSMTPmailsubmission;enablingTLSsupportattheMTAisthenextstep.
Recommendation2:Fixcerticates.
Intheselectproviderset,6ofthe21SMTPMSAsand3ofthe10MTAssupportingTLSprovidedcerticateswithanamethatdidnotmatchtheDNSname.
Thisshouldbexed.
Recommendation3:Verifycerticates.
Certicatesshouldbever-ied,includingthehostname,byallclients(MUAsandoutgoingMTAs).
Giventheabysmallypoornamematching,simplyenablinghostnamevericationwillbreakoverhalfofallmessagepaths.
Anincentive,intheformofdelayedmaildelivery,maybeusefulincompellingmailserveradministratorstodeployTLSsupportandusematchingcerticates.
Recommendation4:RequireTLS.
Manyprovidersofthe22weexaminedalreadyrequireTLSuse.
RequiringTLSeliminatestheriskposedbymisconguredMUAs.
ForMSAsandMDAsusingSTARTTLS,awaytocongurethemailreadertorequireTLSshouldbeprovided.
RFC3207suggeststhatoutgoingmailserversrecordthefactthataparticularincomingMTAusesTLSandensurethatTLSuseinfuturesessions.
WhileRFC3207suggests"generatingawarning,"webelieveastrongerresponse,perhapsdelayingmailorrequiringhumanoperatorintervention,maybeappropriate.
OntheincomingMTAside,thecompatibilityrequirementarticulatedinRFC3207requiresincomingserverstoacceptmailwithoutTLS.
Whilethismaybenecessaryinthegeneralcase,largeprovidersshouldes-tablishbilateralagreementsregardingTLSuse,andrequirethatallconnectionstoaproviderthatsupportsTLStakeplaceoverTLS.
Recommendation5:Certicatepinning.
ToprotectagainstrogueCAattacks,theprovidersshouldxthesetofeachpeer'sallowedcerticatesorCAs.
Giventheoverheadofmaintainingsuchcerti-cateinformation,thisoptionmaybelimitedtoafewlargeproviders.
Recommendation6:UseDKIMandDMARC.
Providersshouldverifysenderidentityandsignalloutgoingmail.
Providersshouldalsopublishastrict("p=reject")policy.
MajorprovidersmayalsoestablishbilateralsigningpoliciesratherthanrelyingonDMARC.
Recommendation7:EnforceSPFandDKIMpolicy.
Receiv-ingprovidersshouldrejectmailfromunauthorizedsenderormailwithamissingorinvalidDKIMsignaturefromsenderswitha"p=reject"policy.
Recommendation8:UseDNSSEC.
DNSrecordsshouldbeau-thenticatedtoprotectagainstactiveattacks.
DNSSECisthepre-ferredmethodfordoingso,andmostTLDs,including.
comand.
org,aresigned.
7.
6OnInteroperabilityvs.
SecuritySecuritypractitionersareoftenfacedwithachoicebetweenin-teroperabilityandsecurity.
Thecaseofemailsecurityisnodif-ferent.
Considercerticateverication,thesubjectofRecommen-dation3.
Ontheonehand,Postel'sPrinciple—beconservativeinwhatyousend,beliberalinwhatyouaccept—advocatestransfer-ringmailevenifthereceivingMTA'scerticateisinvalid.
Ontheotherhand,acceptinganinvalidcerticateleavesthesessionvul-nerabletoaman-in-the-middleattack.
Makingtherighttrade-offrequiresweighinginteroperabilityandsecurityonthesamescale,somethingnotoriouslydifculttodo.
Withtwopartiesinvolved,thesituationbecomesevenmorecomplicated.
LetusconsiderRecommendation3inGame-Theoreticterms.
Wehavetwoplayers,SenderandReceiver,representingthesend-ingMTAandreceivingMTA,respectively.
Receiverhastheoptiontoinstallandmaintainavalidcerticateatsomeadditionalcost,ortheoptionnottodoso.
WhenSenderconnectstoReceiver,hehastheoptiontoverifythecerticate(rejectinganinvalidone)ortoacceptallcerticates(validornot).
LetuscallReceiverstrate-gies"Goodcerticate"and"Badcerticate"denotedGandB,re-spectively,andSenderstrategies"Checkcerticate"and"Acceptcerticate"denotedCandA,respectively.
Therearefourpossibleoutcomesinoursimplegame.
Threeoutoffouroutcomes(GC,GA,andBA)resultinmailbeingtransferredandone(BC)doesnot.
ThelattercorrespondstothecasewhereasendingMTAre-jectsaninvalidcerticateofferedbyareceivingMTA.
Toevaluatethegame,letthecostofmaintainingacerticatebeC.
ThisisthedirectcosttoReceiverofplayingstrategyGandisborneentirelybyReceiver.
IfmailcannotbetransferredbetweenSenderandReceiver,bothincuraloss,perhapsintheformofbranddamage,forfailingtodeliverorreceivemessagesfromeachother.
DenotethelosstotheSenderbyLSandlosstotheReceiverbyLR.
Withoutlossofgenerality,lettheutilityoftransmittingames-sagebeexternal(i.
e.
,zero),sothatthemotivationfortransferringamessageistoavoidthelossassociatingwithnotdoingso.
Finally,letVSandVRbetheexpectedloss,toSenderandReceiver,respec-tively,associatedwithbeingvulnerabletoaman-in-the-middleat-tack.
Notethattheexpectationistakenovertheprobabilityofanattacktakingplaceandthelossincurredfromanattack.
Alterna-tively,wecanconsiderVSandVRtobebranddamageassociatedwithsendingmailunencryptedbetweenSenderandReceiver.
Puttingthesetogether,payoffmatrixforourgameis:SenderCheckcertAcceptcertReceiverGoodcert(C,0)(CVR,VS)Badcert(LR,LS)(VR,VS)Thus,LRandLSaretheinteroperabilitypenalties,VRandVSarethesecuritypenalties,andCisthecostofsecurity,inoutcasebornebyReceiveronly.
Senderstrategy.
FromSender'spointofview,letussaythatRe-ceiverplaysstrategyGwithprobabilityrGandBwithprobabilityrB.
SendershouldchoosestrategyCoverAif:rG·0rBLS>rGVSrBVSVS>rBLS.
Inotherwords,Senderwillprefertoverifycerticatesiftheex-pectedlossfromrejectingmailislessthantheexpectedlossasso-ciatedwithbeingvulnerabletoaman-in-the-middle-attack.
Senderfacesthebasicunilateralsecurity-functionalitytrade-offwithse-curitypenaltyVSandfunctionalitypenaltyrBLS.
Iftheformerisgreaterthanthelatter,Senderwillchosetheformer.
Ifthefunction-alitypenaltyisgreaterthanthesecuritypenalty,shewillchoosethelatter.
Receiverstrategy.
FromtheReceiver'spointofview,lettheprob-abilitythatSenderplaysstrategyCbesCandtheprobabilitythatSenderplaysstrategyAbesA.
ReceiverwouldpreferstrategyGoverBifsCC+sA(CVR)>sCLRsAVRsCLR>C.
Inotherwords,Receiverwillprefertomaintainavalidcerticateiftheexpectedlossfromnotreceivingmailisgreaterthanthecostofmaintainingacerticate.
NotethatReceiver'sstrategydoesnotdependonVR,theexpectedlossassociatedwithbeingvulnerabletoaman-in-the-middleattack.
Nomatterhowprevalentorsevereman-in-the-middleattacksmightbe,Receiver'sstrategydependsonlyonSender'sexpectedbehaviorandthecostofmaintainingacerticate.
Putanotherway,Receiver'sstrategydoesnotdependonsecurity.
Ourresults(Sec.
sec:analysis-cert-out-mta)showthatamongtheselectproviderssCLSthenSenderwillalwayscheckcerticates,and,unlessLRLS),thegamehasoneequilibrium:GC.
Ontheotherhand,ifVSC.
Inotherwords,thesenderstogethershouldtogethergeneratemorethanC/LRofall(non-spam)mail.
WesuspectthatCtobemuchlessthanLR,sothatthemarketshareofprovidersinvolvedinthethreatneednotbeverylarge.
Certainly,thetopthreeprovidersthattogetherrepresentover60%oftheAdobeuserlistarewell-positionedtoeffectsuchachange.
8.
CONCLUSIONModernemailprotocolsprovidemeansforachievingconden-tiality,authenticity,andintegrityduringmessagetransferwithoutanyuserinvolvement.
TLSusewithIMAP,POP,andSMTPpro-videsmessagecondentialityeveninthepresenceofanactiveman-in-the-middleadversary,whileDKIMwithDNSSECensuresauthenticityandintegrity.
Theseguaranteescomeatthecostoftrustingtheemailprovider.
Whileend-to-endmechanismsdonotrequiresuchtrust,useradoptionofPGPandS/MIMEispoor.
Provider-deployedprotocolsconsideredinthispaperprovideacomplemen-tarypathtowardachievingsomeofthesamesecuritygoals.
Inthisworkweexaminedtheuseoftheseprotocolbymajoremailprovidersandemailgenerators.
WefoundthatTLSsupportwascommon,howevercerticatevericationwasvirtuallynon-existent,providingprotectionagainstapassiveadversaryonly.
SPFandDKIMusewasalsocommon,howeverallbutahandfulofprovidersusedDNSSECtoprotecttherequiredDNSrecords.
Inaddition,fewprovidersenforcedSPFpoliciesorrejectedmessageswithinvalidDKIMsignatures.
Moreaggressiveenforcementisre-quiredtoprotectagainstmessageforgeryoractivemessagetam-pering.
AcknowledgmentsWewouldliketothankoursystemadministratorsCindyMooreandBrianKantorandaregratefulforthefeedbackfromtheanonymousreviewers.
ThisworkwassupportedinpartbytheNationalScienceFoundationgrantCNS-1237264andbygenerousresearch,opera-tionaland/orin-kindsupportfromtheUCSDCenterforNetworkedSystems(CNS).
REFERENCES[1]GoogleencryptsdataamidbacklashagainstNSAspying.
TheWashingtonPost,Sept.
2013.
[2]M.
Adkins.
TheCurrentStateofSMTPSTARTTLSDeployment.
https://www.
facebook.
com/notes/1453015901605223,May2014.
[3]Z.
Durumeric,D.
Adrian,A.
Mirian,J.
Kasten,E.
Bursztein,N.
Lidzborski,K.
Thomas,V.
Eranti,M.
Bailey,andJ.
A.
Halderman.
NeitherSnowNorRainNorMITM.
.
.
AnEmpiricalAnalysisofMailDeliverySecurity.
InProceedingsofthe2015InternetMeasurementConference(IMC),2015.
[4]B.
GellmanandA.
Soltani.
NSAinltrateslinkstoYahoo,Googledatacentersworldwide,Snowdendocumentssay.
TheWashingtonPost,Oct.
2013.
[5]S.
Goldberg.
WhyisittakingsolongtosecureInternetroutingCommunicationsoftheACM,57(10):56–63,2014.
[6]B.
Taylor.
FightingphishingwitheBayandPayPal.
http://gmailblog.
blogspot.
com/2008/07/fighting-phishing-with-ebay-and-paypal.
html,July2008.
APPENDIXThisappendixprovidesadditionalinformationonthemailtrans-portprotocolsdescribedinthepaperandtheirsecurityextensions.
SMTPThestandardInternetmailtransferprotocolistheSimpleMailTransferProtocol(SMTP),standardizedin1982byRFC821.
TheoriginalSMTPprovideslittlemorethanauniformmechanismfortransferringmessagesbetweentwohostsoveraTCPconnection.
AcommonSMTPinteractionconsistsofaclientidentifyingitselfus-ingtheHELOcommandandthenpresentingamessagefordeliveryorforwarding.
Onlythesenderandrecipientareidentiedtotheserverexplicitly(viatheMAILFROM:andRCPTTO:commands);theremainderofthemessage,includingheaders,aretransferredasanuninterpretedsequenceofbytes.
Asasimplecommonlanguagebetweendisparatemailsystems,SMTPhadnoprovisionsforen-suringmessageauthenticity,integrity,orcondentiality.
ESMTP.
SMTPwasupdatedin1995withtheabilitytoextendtheprotocolusingextensions.
ThisversionofSMTPiscalledESMTP(RFC1869,obsoletedbyRFC5321).
AnclientindicatesitssupportforESMTPbyissuingtheEHLOinsteadofHELOcommandatthestartofthesession.
IftheserversupportsESMTP,itrespondswithalistofsupportedextensions.
OnesuchextensionisSTARTTLS.
STARTTLSallowsaSMTPsessiontobesecuredwithTLS,andisthepreferredmechanismofdoingso.
SMTPwithSTARTTLSTheSTARTTLSextensionwasintroducedin1999inRFC2487(nowobsoletedbyRFC3207),allowingaSMTPconnectiontobesecuredusingTLS.
AserverindicatessupportfortheSTARTTLSextensionbyincludingtheSTARTTLSkeywordinthelistofsup-portedoptionssenttoaclientinresponsetotheEHLOcommand.
AfterissuingtheSTARTTLScommand,aclientcaninitiateaTLShandshake,afterwhichtheremainderofthesessionissecured.
SMTPSTheSTARTTLSmechanismisthepreferredwaytosecureSMTPsessionswithTLS.
Itisalsopossible,however,toruntheentiresessionoverTLSfromthestart,aswithHTTPS,byinitiatingthehandshakeimmediatelyonconnecting.
WecallthisdirectuseincontrasttoSTARTTLS.
WhenTLSisuseddirectlyforSMTP,theprotocoliscalledSMTPS(lesscommonly,SSMTP).
Toavoidtheneedforserverstoauto-detectTLSuse,port465wasreservedforthisprotocol.
SMTPShassincebeendeprecated;however,manymailprovidersstilluseSMTPSformailsubmission.
RequiringTLS.
RegardingserversrequiringtheuseoftheSTART-TLSextension,RFC3207states:Apublicly-referencedSMTPservermustnotrequireuseoftheSTARTTLSextensioninordertodelivermaillocally.
ThisrulepreventstheSTARTTLSextensionfromdamagingtheinteroperabilityoftheInternet'sSMTPinfrastructure.
Apublicly-referencedSMTPserverisaSMTPserverwhichrunsonport25ofanInternethostlistedintheMXrecord(orArecordifaMXrecordisnotpresent)forthedomainnameontherighthandsideofanInternetmailaddress.
(RFC3207,Sec.
4)ThestandardplacesasimilarrequirementonoutgoingMTAs.
Initsdiscussionofman-in-the-middleattacks,however,RFC3207appearstobackawayfromastrictreadingoftheinteroperabilityrequirement:InordertodefendagainstsuchattacksbothclientsandserversmustbeabletobeconguredtorequiresuccessfulTLSnegotiationofanappropriateciphersuiteforselectedhostsbeforemessagescanbesuccessfullytransferred.
TheadditionaloptionofusingTLSwhenpossibleshouldalsobeprovided.
AnimplementationmayprovidetheabilitytorecordthatTLSwasusedincommunicatingwithagivenpeerandgeneratingawarningifitisnotusedinalatersession.
(ibid.
Sec.
6)Requiringsuccessfulhandshake.
Whilea"publicly-referenced"servermaynotrequireaclienttousetheSTARTTLSextension,onceaclientinitiatesahandshakeafterasuccessfulSTARTTLScommand,bothclientandservermayrefusetoproceed:IftheSMTPclientdecidesthatthelevelofauthenticationorprivacyisnothighenoughforittocontinue,itshouldissueanSMTPQUITcommandimmediatelyaftertheTLSnegotiationiscomplete.
IftheSMTPserverdecidesthatthelevelofauthenticationorprivacyisnothighenoughforittocontinue,itshouldreplytoeverySMTPcommandfromtheclient(otherthanaQUITcommand)withthe554replycode(withapossibletextstringsuchas"Commandrefusedduetolackofsecurity").
(ibid.
Sec.
4.
1)Whatrequirementsclientsandserversshouldenforcearea"localmatter,"accordingtothestandard,however,two"generalrulesforthedecisions"areoffered:(1)ASMTPclientwouldprobablyonlywanttoauthenticateaSMTPserverwhoseservercerticatehasadomainnamethatisthedomainnamethattheclientthoughtitwasconnectingto.
(2)Apublicly-referencedSMTPserverwouldprobablywanttoacceptanyveriablecerticatefromaSMTPclient,andwouldpossiblywanttoputdistinguishinginformationaboutthecerticateintheReceivedheaderofmessagesthatwererelayedorsubmittedfromtheclient.
(ibid.
Sec.
4.
1)InSection5.
3wetestwhetheroutgoingandincomingMTAsfol-lowtheserecommendations.
Init'sdiscussionofsecurityconsider-ations,RFC3207warns:BoththeSMTPclientandservermustchecktheresultoftheTLSnegotiationtoseewhetheranacceptabledegreeofauthenticationandprivacywasachieved.
IgnoringthisstepcompletelyinvalidatesusingTLSforsecurity.
Thedecisionaboutwhetheracceptableauthenticationorprivacywasachievedismadelocally,isimplementation-dependent,andisbeyondthescopeofthisdocument.
(ibid.
Sec.
6)Determiningthedegreeof"authenticationandprivacy"achievedbyTLSuseisthemainsubjectofthiswork.
Section5.
3.
2showsfewserverschecktheresultofTLSnegotiation.
POP3andIMAPThePostOfceProtocol(POP),rstspeciedinRFC918,andtheInternetMessageAccessProtocol(IMAP),rstspeciedinRFC1064,bothallowaclienttoretrievemailstoredonaserver(hop(e)inFigure1).
POPversion3isoftenalsocalledPOP3.
Fromourpointofview,bothPOPandIMAPprovidethesameservice,namelymessagetransferalongthelasthopbetweenMDAandMUA,identiedas(e)inFigure1.
Aswithotherhops,apas-siveattackermayeavesdroponthecommunicationsbetweenMDAandMUA.
Bothend-to-endandtransportencryptionprotectagainstsuchanattack.
Anactiveattackermayalsoattempttoretrieveatar-getuser'smailbyimpersonatingtheuser.
ProtectingagainstsuchimpersonationmeansthattheMDAmustbeabletoensurethattheMUAisactingonthelegitimateuser'sbehalf.
BothPOP3andIMAPhavetraditionallyachievedthisusingplain-textpasswords.
Althoughothermechanismsareavailable,passwordsremainthemainmeansofauthenticationtoday.
Withouttransportencryption,apassiveattackercanrecoverauser'spasswordanduseittore-trievemessagesdirectly.
Notethatend-to-endencryptiondoesnotprotectagainstsuchanattack;theattackercouldstillretrieveauser'sencryptedmail,althoughthecontentofeachmessagewouldbestillbeprotected.
Anactiveattackercanalsocarryoutatradi-tionalman-in-the-middleattack.
IfaMUAdoesnotproperlyau-thenticateaserver,anattackercanrecovertheuser'spasswordandinterceptmessagesretrievedbyauser.
IMAPandPOPwithTLSRFC2595introducedtheSTARTTLSextensiontoPOPandIMAPusingtheextensionmechanismsavailableinnewerversionsofeachprotocol.
AsinSMTP,theSTARTTLSisusedbytheclienttoen-ableTLS.
Afterasuccessfulresponse,theclientinitiatestheTLShandshake.
RFC2595ismoreemphaticthanRFC3207aboutcer-ticatechecking:DuringtheTLSnegotiation,theclientmustcheckitsunderstandingoftheserverhostnameagainsttheserver'sidentityaspresentedintheserverCerticatemessage,inordertopreventman-in-the-middleattacks.
(RFC2595,Sec.
2.
4)RFC2595alsounambiguouslydescribestheidentitycheckingpro-cess.
LikeRFC3207,RFC2595warns:BoththeclientandservermustchecktheresultoftheSTARTTLScommandandsubsequentTLSnegotiationtoseewhetheracceptableauthenticationorprivacywasachieved.
IgnoringthisstepcompletelyinvalidatesusingTLSforsecurity.
Thedecisionaboutwhetheracceptableauthenticationorprivacywasachievedismadelocally,isimplementation-dependent,andisbeyondthescopeofthisdocument.
(ibid.
Sec.
2.
5)IMAPSandPOP3S.
AswithSMTPandSMTPS,beforetheintro-ductionoftheSTARTTLSextension,thecommonmeansofsecur-ingIMAPandPOPwithTLSwastostarttheTLSsessionimme-diately.
TheseprotocolswerecalledIMAPSandPOP3S,anduseTCPports993and995.
Botharestillusedbyemailproviders.
DKIMDKIM(RFC4861,updatedbyRFC6387)introducesprovider-generatedmessagesignaturesintendedtopreventforgeryandtam-peringwithemailfromaprovider.
ADKIMsignature,coveringthemessagebodyandasubsetoftheheaders,isappendedasa"DKIM-Signature"headertothemessage.
Inadditiontothecryp-tographicsignature,aDKIMsignaturealsocontainsaselectoriden-tifyingthekeyusedtogeneratethesignature.
ThecorrespondingpublickeyispublishedinaDNSTXTrecordofselector.
__domainkey.
example.
netwhereselectoristheselectortokenprovidedwiththesignature.
DKIMthusreliesonDNSforkeydistribution.
Itisalsoworthnot-ingthatDKIMdoesnotprovideameansofadvertisingasigningpolicy.
Thus,amessagewithoutasignaturemaybetheresultofthesendernotusingDKIMoranattackerstrippingthesignature.
SPFSPF(RFC4408,updatedbyRFC7208)introducesameansforasendertopublishapolicyidentifyingthenetworkhostswhichmayoriginatemailfromthesender.
ThepolicyisdisseminatedviaaDNSTXTrecordforthedomain.
LikeDKIM,SPFthusreliesontheintegrityofDNS.
TheSPFstandardstatesthatreceivers"should"rejectthemessageimmediatelyduringtheSMTPsessionandcom-municatethisexplicitlytothesendingMTA.
IfthemessageisnotrejectedinthismannerbytheincomingMTA,theMTAshouldadda"Received-SPF"or"Authentication-Results"headertorecordSPFfailure.
Weknowofnomailreadersthatinterpretthisheader,however,built-inspamltersmayusethisasasignal.
ADSPandDMARCFromasecuritypointofview,amajorlimitationofDKIMisthattheabsenceofasignatureisambiguous:eitherthesenderdoesnotimplementDKIMoranattackerisforgingamessageortamperingwithamessage.
ADSP(RFC5617)andDMARC(RFC7489),theformernowhistorical,provideawayforasendertoindicatethataDKIMsignatureshouldbeexpected.
BothADSPandDMARCpublishthisinformationviaDNSTXTrecordsinaspecialsubdo-mainofthedomaininquestion.
AswiththeDNS-basedmecha-nismsabove,recordintegrityinthepresenceofanactivenetworkattackerrequiresuseofDNSSEC.
DNSSECDNSSEC(RFC2535updatedbyRFC4034andothers)providesamechanismforauthenticatingDNSrecordsusingdigitalsigna-tures.
DNSSECalsointroducesahierarchicalpublickeyinfras-tructuremirroringtheDNShierarchy.
TherootkeyisusedtosigneachTLD,eachTLDsignsthenextlevel,andsoon.
VerifyingaDNSSECsignaturesthusrequiresknowingtherootpublickeyngerprint/digest.
Inadditiontoauthenticatingrecords,DNSSECalsoauthenticatesnegativeresults,sothatanactiveattackercannotconvinceavictimthataDNSrecorddoesnotexistbyforginganegativereplyorblockingthelegitimatereply.