Analysis of DTLS ImplementationsUsing Protocol State Fuzzing

Paul Fiterau-BrosteanUppsala University

Bengt JonssonUppsala University

Robert MergetRuhr University Bochum

Joeri de RuiterSIDN Labs

Konstantinos SagonasUppsala University

Juraj SomorovskyPaderborn University

AbstractRecent years have witnessed an increasing number of proto-cols relying on UDP. Compared to TCP, UDP offers perfor-mance advantages such as simplicity and lower latency. Thishas motivated its adoption in Voice over IP, tunneling techno-logies, IoT, and novel Web protocols. To protect sensitive dataexchange in these scenarios, the DTLS protocol has been de-veloped as a cryptographic variation of TLS. DTLS’s mainchallenge is to support the stateless and unreliable transport ofUDP. This has forced protocol designers to make choices thataffect the complexity of DTLS, and to incorporate featuresthat need not be addressed in the numerous TLS analyses.

We present the first comprehensive analysis of DTLS im-plementations using protocol state fuzzing. To that end, we ex-tend TLS-Attacker, an open source framework for analyzingTLS implementations, with support for DTLS tailored to thestateless and unreliable nature of the underlying UDP layer.We build a framework for applying protocol state fuzzing onDTLS servers, and use it to learn state machine models forthirteen DTLS implementations. Analysis of the learned statemodels reveals four serious security vulnerabilities, includinga full client authentication bypass in the latest JSSE version,as well as several functional bugs and non-conformance is-sues. It also uncovers considerable differences between themodels, confirming the complexity of DTLS state machines.

1 Introduction

UDP is widely used as an unreliable transfer protocol forVoice over IP, tunneling technologies, and new Web protocols,and is one of the commonly used protocols in the Internetof Things (IoT). As UDP does not offer any security by it-self, Datagram Transport Layer Security (DTLS) [29,36] wasintroduced. DTLS is a variation on TLS, a widely used secu-rity protocol responsible for securing communication over areliable data transfer protocol.

DTLS is one of the primary protocols for securing IoTapplications [38]. The number of IoT devices is projected to

reach 11.6 billion by 2021 [26]. This will constitute half of alldevices connected to the Internet, with the percentage set togrow in subsequent years. Such trends also increase the needto ensure that software designed for these devices is properlyscrutinized, particularly with regards to its security.

DTLS is also used as one of the two security protocols inWebRTC, a framework enabling real-time communication.WebRTC can be used, for example, to implement video con-ferencing in browsers without the need for a plugin. It issupported by all major browsers, including Mozilla Firefox,Google Chrome, Microsoft Edge, and Apple’s Safari.

Whereas significant effort has been invested into ensuringsecurity of TLS implementations, those based on DTLS haveso far received considerably less scrutiny. Our work fills thisgap by providing an extensible platform for testing and analy-zing systems based on DTLS. We describe this framework,and use it to analyze a number of existing DTLS implementa-tions, including the most commonly used ones. Our specificfocus is on finding logical flaws, which can be exposed bynon-standard or unexpected sequences of messages, using atechnique known as protocol state fuzzing (or simply state fuz-zing).

As in TLS, each DTLS client and server effectively imple-ments a state machine which keeps track of how far protocoloperation has progressed: which types of messages have beenexchanged, whether the cryptographic materials have beenagreed upon and/or computed, etc. Each DTLS implementa-tion must correctly manage such a state machine for a numberof configurations and key exchange mechanisms. Correspon-ding implementation flaws, so-called state machine bugs, maybe exploitable, e.g., to bypass authentication steps or establishinsecure connections [5]. To find such flaws, state fuzzinghas proven particularly effective not only for TLS [13], butalso for SSH [19], TCP [18], MQTT [40], OpenVPN [12],QUIC [33], and the 802.11 4-Way Handshake [28], leadingto the discovery of several security vulnerabilities and non-conformance issues in their implementations.

State fuzzing automatically infers state machine descripti-ons of protocol implementations using model learning [32,41].

This is an automated black-box technique which sends se-lected sequences of messages to the implementation, observesthe corresponding outputs, and produces a Mealy machinethat abstractly describes how the implementation responds tomessage flows. The Mealy machine can then be analyzed tospot flaws in the implementation’s control logic or check com-pliance with its specification. State fuzzing works without anya priori knowledge of the protocol state machine, but relieson a manually constructed protocol-specific test harness, a.k.a.a MAPPER, which translates symbols in the Mealy machineto protocol packets exchanged with the implementation.

Challenges resulting from the DTLS design. DTLS ismore complex than other security protocols that have so farbeen subject to state fuzzing. Most of these [12, 18, 19] runover TCP, relying on its support for reliable connections. Incontrast, DTLS runs over UDP, which is connectionless. Thisimplies that DTLS has to implement its own retransmissionmechanism and provide support for message loss, reordering,and fragmentation. Moreover, an ongoing DTLS interactioncannot be terminated by simply closing the connection, as isthe case with TLS. As a result, most DTLS implementationsallow interaction to continue even after reception of unex-pected messages —after all, these messages might have justarrived out of order— and may subsequently allow a hands-hake to “restart in the middle” and finish successfully. Finally,compared to TLS, DTLS includes an additional message ex-change used to prevent Denial-of-Service attacks. All thisadded complexity makes protocol state fuzzing more difficultto apply for DTLS than for TLS.

Supporting mapper construction. DTLS’ support formessage loss, reordering, and fragmentation requires additio-nal packet parameters compared to TLS, such as message se-quence numbers. DTLS parameters have to be correctly mana-ged by the MAPPER. This requires special care when deviatingfrom an expected handshake sequence (a.k.a. a happy flow),since each particular parameter management strategy mayallow or prohibit a “restarting” handshake to be eventuallycompleted. In order to facilitate MAPPER construction andparameter management, we have developed a test frameworkfor DTLS, which allows easy definitions of arbitrary protocolpackets and efficient experimentation with parameter manage-ment strategies. This test framework is realized by extendingTLS-Attacker [39], an existing open source framework fortesting TLS implementations, with support for DTLS. Theframework forms the basis for our MAPPER used for DTLSstate fuzzing. The test framework can also be used in its ownright to support other fuzzing techniques.

Handling the complexity of DTLS state machines. Theabove properties of DTLS imply that state machine modelsof DTLS implementations are significantly more complexthan corresponding state machines for TLS and other proto-cols. Their complexity is further increased when analyzingthe four main key exchange mechanisms together rather than

separately, and when exploring settings involving client certi-ficate authentication. Such complexity in the models createsproblems both for the model learning algorithm and for theinterpretation of resulting models. We ameliorate and avoidsome of the complexity in two ways: 1) Our test harness doesnot employ reordering and fragmentation, and hence this isnot part of our learned models. 2) We adapt the MAPPER soas to enable handshakes to “restart”, which has the additionalside-effect of decreasing the size of the learned models, sincesuccessful restarts typically show up as back-transitions toregular handshake states.Obtaining models for a wide range of implementationsand configurations. We have applied our platform to thirteenimplementations of ten distinct vendors (Section 6). Besidescovering a wide spectrum of DTLS implementations, rangingfrom mature, general-purpose libraries to implementationsdesigned for IoT or WebRTC, we mention that some of themare DTLS libraries without a TLS component, on which statefuzzing has never been applied before.

For each implementation we examine many, often all, com-binations of supported key exchange and client certificateauthentication configurations. This ensures that state fuzzingdoes not miss bugs that are only present in certain configurati-ons. In fact, this proved important: several of the Java SecureSocket Extension (JSSE) bugs reported in Section 7.4 couldonly have been discovered with a configuration requiringclient certificate authentication.From models to bugs. Once models are obtained we proceedto analyze them, looking for unexpected or superfluous statesand transitions. Some of the main findings of our analysis are:(i) A complete client authentication bypass in JSSE, which isthe default TLS/DTLS library of the Java Standard EditionPlatform. The bug allows attackers to authenticate themselvesto a JSSE server by sending special out-of-order DTLS mes-sages without ever proving to the server that they know theprivate key for the certificate they transmit. The bug is especi-ally devastating, since it also affects JSSE’s TLS library. Thisgreatly increases its impact, as JSSE’s TLS library is oftenused to authenticate users with smart cards at web sites orweb services. (ii) A state machine bug in the Scandium frame-work allowed us to finish a DTLS handshake without sendinga ChangeCipherSpec message. This resulted in the serveraccepting plaintext messages even if indicated otherwise bythe negotiated cryptographic mechanisms. Note that this bugis similar to the EarlyFinished bug found in the TLS JSSEimplementation [13]. (iii) A similar bug was also present inPionDTLS, a Go implementation for WebRTC. Investigationof this bug led to discovery of a graver issue whereby thePionDTLS server freely processes unencrypted applicationdata once a handshake has been completed. (iv) Finally, threeconfirmed functional bugs in TinyDTLS, a lightweight DTLSimplementation for IoT devices.Contributions. In summary, this work:

• Extends TLS-Attacker with DTLS functionality and

uses it to implement a protocol state fuzzing platformfor DTLS servers.

• Provides Mealy machine models for thirteen DTLS ser-ver implementations, including the most commonly usedones, with models exploring most key exchange algo-rithms and client certificate authentication settings.

• Analyzes the learned models and reports several non-conformance bugs and a number of security vulnerabili-ties in DTLS implementations. Some of these vulnerabi-lities affect also the TLS part of these libraries.

Responsible disclosure. We have reported all issues to therespective projects complying with their security procedures.The reported security issues were all confirmed by the respon-sible developers, who implemented proper countermeasures.We provide more details in Section 7.Outline. We start by briefly reviewing DTLS, model learning,and the TLS-Attacker framework in Sections 2 to 4. Subse-quently, we present the learning setup we employ (Section 5),the DTLS server implementations we tested and the effortspent on learning state machines for them (Section 6), follo-wed by a detailed analysis of the issues that were found in thevarious DTLS implementations (Section 7). Therein, we pre-sent state machines for three of these implementations, whilstmaking the rest available online. Section 8 reviews relatedwork, and Section 9 ends this paper with some conclusionsand directions for further work.

2 Datagram Transport Layer Security

DTLS is an adaptation of TLS [15] for datagram transportlayer protocols. It is currently available in two versions:DTLS 1.0 [35], based on TLS 1.1 [14], and DTLS 1.2, basedon TLS 1.2 [15]. Version 1.3 is currently under development.This work focuses on TLS/DTLS version 1.2.

At a high level, both TLS and DTLS consist of two majorbuilding blocks: (1) The Handshake is responsible for nego-tiating session keys and cryptographic algorithms, and keyagreement is either based on public key cryptography (thestandard case), or on pre-shared keys. The set of algorithmsto be used is specified in a cipher suite. (2) The Record Layersplits the received cleartext data stream into DTLS Records.Handshake messages are also sent as records (typically unen-crypted), and after the ChangeCipherSpec message is sentin the handshake, the content of all subsequent records is en-crypted using the negotiated session keys—where differentkeys are used for the two communication directions.

The stateless and inherently unreliable datagram transportlayer has prompted the designers of DTLS to introduce severalchanges to the original TLS protocol. Below, we describethe handshake protocol and Record Layer, and discuss thechanges introduced which are relevant to our paper. However,we remark that more differences exist [29, 36].

Client Serverflight 1 ClientHello

flight 2HelloVerifyRequestflight 3 ClientHello

flight 4

ServerHello[Certificate]

[ServerKeyExchange][CertificateRequest]

ServerHelloDone

flight 5

[Certificate]ClientKeyExchange[CertificateVerify]

ChangeCipherSpec{Finished}

flight 6ChangeCipherSpec{Finished}

flight 7 {Application}

Figure 1: DTLS handshake. Encrypted messages are insidebraces. Optional messages are inside square brackets. Messa-ges specific to DTLS are in blue.

Handshake protocol. Figure 1 illustrates the DTLS hands-hake. The client initiates communication by sending Client-Hello, which includes the highest supported DTLS versionnumber, a random nonce, the cipher suites supported by theclient, and optional extensions. In DTLS, the server respondswith a HelloVerifyRequest message, which contains a statelesscookie. This message prompts the client to resend the Client-Hello message, which then includes the stateless cookie, andattempts to prevent Denial-of-Service attacks [36].

The server responds with the following messages: Server-Hello contains the server’s DTLS version, the cipher suitechosen by the server, a second random nonce, and optionalextensions. Certificate carries the server’s certificate, whichcontains the server’s public key. In ServerKeyExchange theserver sends an ephemeral public key which is signed withthe private key for the server’s certificate. This signature alsocovers both nonces. CertificateRequest asks the client to au-thenticate to the server. This message is optional, and onlyused when the server is configured to authenticate clients viacertificates. ServerHelloDone marks that no other messagesare forthcoming.

The client responds with a list of messages: Certifi-cate, ClientKeyExchange, CertificateVerify, ChangeCipher-Spec, and Finished. The Certificate and CertificateVerify mes-sages are optional and only transmitted when the server reque-sts client authentication. They contain, respectively, a clientcertificate and a signature computed over all previous messa-ges with the client’s long term private key. The client sends itspublic key share in the ClientKeyExchange message. Both par-ties then use the exchanged information to derive symmetric

keys that are used in the rest of the protocol. The client sendsChangeCipherSpec to indicate that it will use the negotiatedkeys from now in the Record Layer. Finally, it sends Finishedencrypted with the new keys, which contains an HMAC overthe previous handshake messages. The server responds withits own ChangeCipherSpec and Finished messages. There-after, both client and server can exchange authenticated andencrypted application data.

Several DTLS handshakes can be performed within oneDTLS connection. Performing a subsequent handshake allowsthe client and server to renew the cryptographic key material.This process is also called renegotiation.

UDP datagrams are often limited to 1500 bytes [36]. Sincehandshake messages can become longer than the datagramsize, a fragmentation concept has been introduced in DTLS.This allows the implementation to split a handshake messageinto several fragments and send it over the wire in distinctrecords so that every record respects the maximum datagramsize. To support this, new fields have been introduced in thehandshake messages: message sequence, fragment offset, andfragment length. Message sequence indicates the positionof the message within the handshake and is also used in aretransmission mechanism.

Record Layer. All messages in DTLS are wrapped in so-called records. During the first DTLS handshake, the RecordLayer operates in epoch 0. This epoch number is included inthe header of the DTLS record. If cryptographic keys havebeen negotiated and activated by sending a ChangeCipher-Spec, the Record Layer increases the epoch number to 1 whichindicates that the contents of the actual record are encrypted.Since the handshake may be repeated several times (renegoti-ation), the epoch number may also be increased further.

While TLS has implicit sequence numbers, DTLS has expli-cit sequence numbers. This is required since the protocol doesnot guarantee message arrival and therefore cannot guaranteethat the implicit counters are synchronized. At the start ofeach epoch, sequence numbers are reset to 0, and for each newrecord the sequence number is increased. Note that re-sendinga record due to the loss of a UDP packet still increases thesequence number.

3 Background on Model Learning

Our state fuzzing framework infers a model of a protocolimplementation in the form of a Mealy machine, which des-cribes how the implementation responds to sequences ofwell-formed messages. Mealy machines are finite state auto-mata with finite alphabets of input and output symbols. Theyare widely used to model the behavior of protocol entities(e.g., [10, 25]). Starting from an initial state, they processone input symbol at a time. Each input symbol triggers thegeneration of an output symbol and brings the machine to anew state.

To infer a Mealy machine model of an implementation,we use model learning. An analyzed implementation is re-ferred to as the system under test (SUT). Model learning isan automated black-box technique which a priori needs toknow only the input and output alphabets of the SUT. Themost well-known model learning algorithm is Angluin’s L∗

algorithm [3], which has been refined into more efficient ver-sions, such as the TTT algorithm [22] which is the one we use.These algorithms assume that the SUT exhibits deterministicbehavior, and produce a deterministic Mealy machine.

Model learning algorithms operate in two alternating pha-ses: hypothesis construction and hypothesis validation. Du-ring hypothesis construction, selected sequences of input sym-bols are sent to the SUT, observing which sequences of outputsymbols are generated in response. The selection of inputsequences depends on the observed responses to previoussequences. When certain convergence criteria are satisfied,the learning algorithm constructs a hypothesis, which is aminimal deterministic Mealy machine that is consistent withthe observations recorded so far. This means that for inputsequences that have been sent to the SUT, the hypothesis pro-duces the same output as the one observed from the SUT. Forother input sequences, the hypothesis predicts an output byextrapolating from the recorded observations. To validate thatthese predictions agree with the behavior of the SUT, lear-ning then moves to the validation phase, in which the SUT issubject to a conformance testing algorithm which aims to va-lidate that the behavior of the SUT agrees with the hypothesis.If conformance testing finds a counterexample, i.e., an inputsequence on which the SUT and the hypothesis disagree, thehypothesis construction phase is reentered in order to builda more refined hypothesis which also takes the discoveredcounterexample into account. If no counterexample is found,learning terminates and returns the current hypothesis. Thisis not an absolute guarantee that the SUT conforms to thehypothesis, although many conformance testing algorithmsprovide such guarantees under some technical assumptions. Ifthe cycle of hypothesis construction and validation does notterminate, this indicates that the behavior of the SUT cannotbe captured by a finite Mealy machine whose size and com-plexity is within reach of the employed learning algorithm.

Model learning algorithms work in practice with finite inputalphabets of modest sizes. In order to learn realistic SUTs, thelearning setup is extended with a so-called MAPPER, whichacts as a test harness that transforms input symbols fromthe finite alphabet known to the learning algorithm to actualprotocol messages sent to the SUT, as illustrated in Fig. 2.Typically, the input alphabet consists of different types of mes-sages, often refined to represent interesting variations, e.g.,concerning the key exchange algorithm. The MAPPER trans-forms each such message to an SUT message by supplyingmessage parameters, performing cryptographic operations,etc. Conversely, the MAPPER translates output from the SUTinto the alphabet of output symbols known to the learning

algorithm. The MAPPER also maintains state that is hiddenfrom the learning algorithm but needed for supplying mes-sage parameters; this can include sequence numbers, agreedencryption keys, etc. The choice of input alphabet and the de-sign of the MAPPER require domain specific knowledge aboutthe tested protocol. Once the mapper has been implemented,model learning proceeds fully automatically.

4 DTLS Framework Implementation

The Transport Layer Security (TLS) protocol is one of themost important cryptographic protocols used on the Internet.Due to its importance and widespread deployment, TLS andits various attacks [2,4,5,7,13,30,43] have been under scrutinyby security researchers. As a result, by now, there exist severalframeworks [6, 24, 31, 39] for the evaluation of TLS libraries.In contrast, DTLS has been largely overlooked in these fra-meworks or considered out of scope. Instead of starting fromscratch, we have decided to create a framework for testingDTLS based on the newest version of TLS-Attacker [39].

4.1 TLS-AttackerTLS-Attacker is an open-source, flexible Java-based TLS ana-lysis framework that allows its users to create and modifyTLS protocol flows as well as the structure of the includedTLS messages. The user is then able to test and analyze thebehavior of an implementation, and create attacks and toolswith the custom TLS stack of TLS-Attacker as a softwarelibrary. TLS-Attacker has been integrated in the build processof several TLS libraries [8, 27] to increase their test coverage.

TLS-Attacker employs solely the low-level cryptographyprovided by Java, and implements the TLS protocol itself. Itsmain functionality relies on the concept of workflow traceswhich allow to define arbitrary protocol flows. Every TLSprotocol flow can be represented by a sequence of Send andReceive actions. The developer can construct a workflow tracein Java or in XML. Once TLS-Attacker receives a workflowtrace, it attempts to execute the predefined TLS messages, andrecords the behavior of the tested TLS peer. A Java examplewith an ECDHE-RSA key exchange is shown below:WorkflowTrace flow = new WorkflowTrace();trace.addTlsActions(new TlsAction[]{new SendAction(conn, new ClientHelloMessage()),new ReceiveAction(conn, new ServerHelloMessage()),new ReceiveAction(conn, new CertificateMessage()),new ReceiveAction(conn, new ECDHEServerKeyExchangeMessage()),new ReceiveAction(conn, new ServerHelloDoneMessage()),new SendAction(conn, new ECDHClientKeyExchangeMessage()),new SendAction(conn, new ChangeCipherSpecMessage()),new SendAction(conn, new Finished()),new ReceiveAction(conn, new ChangeCipherSpecMessage()),new ReceiveAction(conn, new Finished())

});

Notice how messages in the above flow are described at a highlevel. To execute flows, TLS-Attacker generates valid packetsfor messages, and parses messages from packet responses. It

LEARNERMAPPER

[TLS-Attacker] SUT

ClientHello Record(..ClientHello(..))

Record(..ServerHello(..))ServerHello

Figure 2: DTLS Learning Setup.

does this by maintaining a context, which it updates as newmessages are sent and received. The context encompassesstateful information relevant to a TLS connection such asstored random nonces, agreed upon algorithms, and suppor-ted cipher suites. Using this information, TLS-Attacker cangenerate valid or semi-valid messages, encrypt them usingthe negotiated cipher suite, and send them to a peer.

All the above properties make TLS-Attacker ideal for gene-rating valid packets from message names, which in our caseare the symbols of the input alphabet.

4.2 Our DTLS Testing FrameworkOur DTLS testing framework extends TLS-Attacker with sup-port for DTLS 1.0 and DTLS 1.2. This extension allows TLS-Attacker to generate, send and receive DTLS packets and,more broadly, to execute valid and invalid DTLS flows. Ourimplementation involved several changes, among which wemention: i) added support for DTLS handshake message frag-mentation; ii) a new field to the ClientHello message forstoring a server cookie; iii) new fields to the TLS context, onefor storing the cookie received, others for keeping track ofthe record epoch and message sequence number (how thesefields are updated is explained in Section 5.2); and iv) newoptions for retransmission and fragmentation handling.

5 Learning Setup

The learning setup1 comprises three components: theLEARNER, the MAPPER and the SUT; cf. Fig. 2. The SUT is aDTLS server implementation, though our setup can be easilyadapted to support clients. The LEARNER generates inputsfrom a finite alphabet of input symbols. The MAPPER trans-forms these inputs into full DTLS records and sends them overa datagram connection to the SUT. The MAPPER then captu-res the SUT’s reply, translates it to symbols in the alphabetof output symbols, and delivers them back to the LEARNER.The LEARNER finally uses the information obtained from theexchanged sequences of input and output symbols to generatea Mealy machine, as described in Section 3.

5.1 LearnerThe LEARNER is implemented using LearnLib [23], a Javalibrary implementing algorithms for learning automata andMealy machines. The library also provides state-of-the art

1Available at https://github.com/assist-project/dtls-fuzzer/

Table 1: Symbols used in learning and their shorthands. Welist only the output symbols which are mentioned in the paper.

Symbol Shorthand

ClientHello(T) CH(T)T ∈ {DH,ECDH,RSA,PSK}

CertificateRequest CertReqClientKeyExchange(T) CKE(T)

T ∈ {DH,ECDH,RSA,PSK}CertificateVerify CertVerEmptyCertificate Cert(empty)Certificate(T) Cert(t)

T ∈ {RSA,ECDSA} t ∈ {RSA,EC}ChangeCipherSpec CCSApplication AppAlert(CloseNotify) A(CN)Alert(UnexpectedMessage) A(UM)Alert(BadCertificate) A(BC)Alert(DecodeError) A(DE)Alert(DecryptError) A(DYE)Alert(InternalError) A(IE)HelloVerifyRequest HVRServerHello SHServerHelloDone SHDServerKeyExchange(T) SKE(T)

T ∈ {DH,ECDH,PSK}Finished FNoResp -Disabled DisabledUnknown Message UM

inpu

talp

habe

tou

tput

alph

abet

conformance testing algorithms, which are used by the lear-ning algorithm for hypothesis validation. The learning algo-rithm chosen is TTT [22], a state-of-the-art algorithm thatrequires fewer test inputs compared to other algorithms [21].For conformance testing, we use Wp [11] and a variation ofit, Wp-Random [20].

Table 1 displays the alphabets of input and output symbols,as well as the shorthands that we use to make their represen-tation more compact. The input alphabet includes in abstractform all client messages introduced in Section 2. Additionally,it includes Application for sending a simple application mes-sage, and two common alert messages, Alert(CloseNotify) andAlert(UnexpectedMessage). (Interpretations for the alerts canbe found in the TLS 1.2 specification [15, p. 31].) Finally, Cer-tificate, EmptyCertificate, and CertificateVerify are includedfor sending certificate-related messages. Certificate containsa single valid certificate, and is parameterized by the publickey signing algorithm. EmptyCertificate denotes sending acertificate message with an empty list of certificates.

The output alphabet includes abstractions for each diffe-rent message the SUT responds with, similarly to the inputalphabet. It also includes three special outputs: NoResp, whenthe SUT does not respond; Disabled, when the SUT processis no longer running; and Unknown, when the SUT responds

with a message which cannot be decrypted by the MAPPER.This happens, for example, if the MAPPER has replaced thekeys necessary to decrypt the output by a new set of keys.

5.2 Mapper

The MAPPER uses our DTLS testing framework to translatebetween LEARNER inputs/outputs and actual DTLS messages.Behaviorally, the MAPPER operates like a DTLS client, withcontrol flow deferred to the LEARNER. In order to reduce thelearning effort, we do not subject the SUT to message reor-dering or fragmentation. Hence, the MAPPER is configured tosend each handshake message in one single DTLS fragment.

To correctly supply and check DTLS-specific fields in mes-sages, the MAPPER maintains the state of the interaction ina context, which it uses to generate and parse messages. OurDTLS testing framework already maintains such a context forexecuting protocol flows. Hence, we let our MAPPER use thiscontext, with a few adaptations to support efficient learning.Key components of this context are cookie, cipherState anddigest, as well as nextSendMsgSeq and nextRecvMsgSeq, forthe next message sequence number to be sent and received,respectively. Each message sent is equipped with the value ofnextMsgSeqSent, which is then incremented. nextRecvMsgSeqis assigned the sequence number of each message received,provided it is the next expected one. The MAPPER also main-tains analogous state variables for record sequence numbers,as well as numbers of epochs that are incremented whenevera ChangeCipherSpec is sent. These variables are also usedto assemble fragments into messages and detect retransmissi-ons. Retransmissions here refer to messages whose messagesequence number or epoch are smaller than those expected.

The variable cookie, initially set to empty, retains the va-lue of the cookie field in the most recent HelloVerifyRequestmessage received from the server, and is used when sendingsubsequent ClientHello messages. The variable cipherStatestores the next symmetric keys to be used for decrypting/en-crypting messages. To be put in use, a cipherState first hasto be deployed. The cipherState deployed initially is set tonull (no encryption/decryption). On each ClientKeyExchangesent, cipherState is updated using information from an ear-lier ClientHello-ServerHello exchange. On each ChangeCip-herSpec sent, cipherState is deployed. This implies that theMAPPER will only start encrypting/decrypting once Client-Hello and ServerHello are exchanged, and a ClientKeyEx-change and a ChangeCipherSpec have been issued. Prior tothese actions, messages are sent in plaintext.

The variable digest stores a buffer of all handshake messa-ges sent so far, i.e., each handshake message that is sent orreceived is also appended to digest. A hash over this variableis included in every Finished message sent, to be verified bythe server. The variable digest is cleared after each Finished,and also before sending ClientHello. This strategy for reset-ting digest enables handshakes to “restart in the middle”, by

ensuring that hashes are computed over exactly the messagesin the most recent current handshake. After experimentingwith different strategies for resetting digest, we found thatthis strategy allows handshakes that restart to complete, whe-reas other strategies do not. It also produces smaller learnedmodels, since successful restarts typically show up as back-transitions to regular handshake states. As an example, forTinyDTLS using a PSK configuration, the number of statesin the learned model was reduced from 36 if digest was notreset, to 22 if it was.

5.3 Making the SUT Behavior Deterministic

As mentioned in Section 3, the learning algorithm employedworks under the assumption that the SUT exhibits determinis-tic behavior, i.e., the output generated depends uniquely on thesupplied input sequence. During learning experiments, howe-ver, timing effects occasionally manifest as non-determinismto the time-agnostic LEARNER. Below, we describe our stra-tegies to remedy this problem.

One cause for timing-induced non-determinism is theLEARNER sending the first input too early, before the SUT hasfully started, or the MAPPER determining prematurely that theSUT does not respond. We address this by tailoring, for eachSUT, the start and response timeouts. These are, respectively,the delay before the first input is sent (allowing the SUT toinitialize), and the time the MAPPER waits for each responsebefore concluding a timeout. In order to reduce learning time,we adjust the response timeout for certain messages, parti-cularly ClientHello and Finished, to which the SUT couldtake longer to respond. Finally, in order to optimize the starttimeout for the slower JSSE and Scandium implementations,we wrap around the SUT a program which preloads key ma-terial, among other things. This key material is then reusedrather than reloaded for each new sequence of inputs. Oncethe server is ready to receive packets, the wrapper program no-tifies the LEARNER of the port number at which the server islistening. The LEARNER can then immediately start sendinginputs, rather than having to wait for a predefined period.

Another cause for non-determinism is timeout-triggeredretransmissions by the SUT. To address this, we set the re-transmission timeout of the SUT to a high value. For someSUTs, this is a configurable parameter; for others we had toalter the source code. Corresponding patches are provided onthe learning setup’s website for reproducibility.

Even with the above strategies, an SUT would sometimesproduce alternative outputs due to spurious timing effects.In order to detect such cases, we store SUT’s responses toqueries in a cache during the hypothesis construction phase,and confirm each counterexample produced by hypothesis va-lidation before delivering it to the LEARNER. When detectinga case of differing responses to the same input, we rerun thesequence until at least 80% of the responses are the same; thisalways happened within a small number of retrials.

6 Experimental Setup and Experiments

An experiment configuration comprises the implementation,the key exchange algorithms and client authentication settingbased on which we form the input alphabet, and whethermessages with retransmissions were discarded.

6.1 Implementations Tested and Analyzed

In total, we analyzed thirteen different implementations. Thisincludes well-known TLS implementations like OpenSSL,GnuTLS, MbedTLS, JSSE, WolfSSL, and NSS, which alsosupport DTLS. For JSSE we analyzed the Sun JSSE provi-der of Java 9 and 12. Furthermore, we analyzed PionDTLS,a Go implementation of DTLS 1.2 for WebRTC. The re-maining implementations are IoT-specific and support onlyDTLS. Scandium is the DTLS implementation which is partof Eclipse’s Java CoAP implementation. The two TinyDTLSvariants are lightweight implementations specifically desig-ned for IoT devices. TinyDTLS for Contiki-NG branchedout from that in Eclipse’s IoT suite, and has been develo-ped independently ever since. We refer to Eclipse’s variantas TinyDTLSE , and to Contiki-NG’s as TinyDTLSC. Whenreferring to both, we simply use TinyDTLS. For GnuTLSand Scandium, we analyzed two versions; the later versioncontains bug fixes uncovered in the earlier one. As withTinyDTLS, we omit versions when referring to both.

To avoid having to write our own DTLS servers, we use uti-lities to configure and launch DTLS servers that are providedby the developers where possible. For example, for OpenSSL,we use the openssl s_server utility, for GnuTLS we usegnutls-serv, etc. There are three exceptions (PionDTLS,Scandium, and JSSE) for which we wrote our own DTLS ap-plications2 as either there were no standard utilities availableor the available ones did not provide the desired functiona-lity. For every implementation, Table 2 displays the name,version, utility, supported key exchange algorithms and clientcertificate authentication configurations, and a URL. We usecommit identifiers as versions for both TinyDTLS variants,PionDTLS, and Scandium. The two commits for Scandiumbelong to the development version 2.0.0 and shall, more sug-gestively be referred to as Scandiumold and Scandiumnew.Note that client certificate authentication is relevant for DH,ECDH and RSA, but not for PSK whose handshake does notincorporate certificate messages [17, p. 4].

The input alphabet, described in Table 1, includes inputsnecessary to perform handshakes using every key exchangealgorithm supported, two alerts, and one application message.Whenever certificates can be part of the key exchange algo-rithm, they are also included in the alphabet. The SUT isconfigured to use client certificates whenever these are sup-ported. Therein we explore three configurations: (i) required:

2These implementations are accessible via the learning setup’s website.

Table 2: DTLS implementations tested. ”-” means a custom program was provided. Client certificate authentication can bedisabled (NONE), required (REQ) and optional (OPT). Grayed out or slanted are configurations supported by the library butnot made available by the utility. For slanted configurations this support was added, which enabled testing them. Braces gatherconfigurations explored via single learning experiments.

Name Version Utility Algorithms Client Cert Auth URL

GnuTLS 3.5.19gnutls-serv

DH,ECDH,RSA,PSK︸ ︷︷ ︸ NONE,REQ,OPT︸︷︷︸ https://www.gnutls.org3.6.7 DH,ECDH,RSA,PSK︸ ︷︷ ︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT︸︷︷︸

JSSE 9.0.4 - DH,ECDH,RSA︸︷︷︸ NONE,REQ︸︷︷︸,OPThttps://www.oracle.com/java/

12.0.2 DH︸︷︷︸,ECDH︸ ︷︷ ︸,RSA︸︷︷︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT︸︷︷︸MbedTLS 2.16.1 ssl-server2 DH,ECDH,RSA,PSK︸ ︷︷ ︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT︸︷︷︸ https://tls.mbed.org

NSS 3.46 tstclnt DH,ECDH,RSA︸ ︷︷ ︸ NONE︸ ︷︷ ︸,REQ,OPT https://nss-crypto.org

OpenSSL 1.1.1b openssl s_server DH,ECDH,RSA,PSK︸ ︷︷ ︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT︸︷︷︸ https://www.openssl.org

PionDTLS e4481fc - ECDH︸ ︷︷ ︸,PSK︸︷︷︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT︸︷︷︸ https://github.com/pion/dtls

Scandiumold c7895c6 - ECDH︸ ︷︷ ︸,PSK︸︷︷︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT︸︷︷︸ https://www.eclipse.org/californium/Scandiumnew 6979a09 ECDH︸ ︷︷ ︸,PSK︸︷︷︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT︸︷︷︸TinyDTLSC 53a0d97 dtls-server ECDH︸ ︷︷ ︸,PSK︸︷︷︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸ https://github.com/contiki-ng/tinydtls

TinyDTLSE 8414f8a dtls-server ECDH︸ ︷︷ ︸,PSK︸︷︷︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸ https://github.com/eclipse/tinydtls

WolfSSL 4.0.0 server DH,ECDH,RSA︸ ︷︷ ︸,PSK︸︷︷︸ NONE︸ ︷︷ ︸,REQ︸︷︷︸,OPT https://www.wolfssl.com

a valid certificate is requested (via CertificateRequest mes-sage) and required to complete a handshake; (ii) optional:a valid certificate is requested but not required; and (iii) di-sabled: a valid certificate is neither requested nor required.These configurations are further detailed in Section 7.1.

In some experiments, we had to remove inputs from theinput alphabet and/or limit the set of explored configurations.For PionDTLS, NSS and WolfSSL, the reason was that theserver program or library does not support certain combinati-ons of key exchange algorithms and certificate configurations.Similarly, PionDTLS’s library does not allow PSK and ECDHcipher suites to be used together, NSS’s utility does not sup-port certificate authentication, whilst WolfSSL’s utility couldnot be configured to simultaneously support all key exchangealgorithms. In cases where learned models were large (forTinyDTLS, Scandium, and JSSE) or when response time wasslow (for Scandium and JSSE), we generated models sepa-rately for each key exchange algorithm, in order to keep thelearning time reasonable.

6.2 Learning EffortIn our experiments, model learning converged on all analy-zed implementations, except for JSSE (all configurations),WolfSSL with disabled client authentication, and Scandiumusing ECDH alphabets. For these configurations, the lasthypothesis models produced by learning are not complete,but still very informative as bases for analysis.

Statistics from the learning experiments for which modellearning converged are shown in Table 3. These include thenumber of states, number of tests, and learning time. Ouranalysis focuses on these three quantities.Number of states. First, note that the number of states in all

models is a two-digit number. This means that the modelswe learn for these DTLS implementations are non-trivial. Inparticular, we remark that the number of states is considerablylarger than those reported for TLS implementations, with ourDTLS models averaging 25 states while the TLS models areaveraging 9 states [13]. This confirms our expectations aboutthe increased complexity of DTLS, and the complexity thatlearning with several cipher suites adds to most models.

Second, the number of states is, unsurprisingly, affected bythe alphabet configuration. PSK configurations generally leadto smaller models than ECDH ones. (This is expected, sincethe handshake sequence is longer unless client certificate au-thentication is disabled.) However, combining multiple ciphersuites in one alphabet does not necessarily result in muchlarger models. For example, OpenSSL or MbedTLS generaterelatively small models (19 and 17 states respectively, whenauthentication is required) even with four cipher suites. Thiscan be explained by the fact that in mature implementationshandshakes for different key exchange algorithms/authenti-cation configurations tend to share states. (For example, inFig. 3 note how all handshakes finish in states 5 and 6.)

Third, as we will soon see, there appears to be a strong cor-relation between the number of states and bugs. The most con-sequential bugs were found in implementations generating thelargest models (JSSE, PionDTLS, Scandiumold , TinyDTLS).Hence, reducing state machine size is a viable strategy forimproving software correctness.Number of tests. The number of tests was between 21 000and 50 000 for most implementations, with only PionDTLSand GnuTLS 3.6.7 requiring considerably more. Implemen-tations which resulted in the largest models also requiredthe most tests. PionDTLS leads in terms of model size (66states) and number of tests (113 508). The one exception to

Table 3: Results of learning experiments. The “Timeout“ column refers to the response timeout, to which ∗ is appended in casethe timeout was adjusted based on the input. The “Alphabet Used” column describes the type of cipher suites used, if certificateinputs were included (CERT), if authentication was disabled (NONE), optional (OPT) or required (REQ), and if retransmissionswere discarded (DISC).

Implementation Timeout Alphabet Used States of Hypotheses Tests Tests to last Timeand Version (msecs) Final Model Hypothesis (mins)

GnuTLS 3.5.19 200 PSK+RSA_CERT_OPT 29 18 46276 5921 3577

GnuTLS 3.6.7 50∗DH+ECDH+PSK+RSA_CERT_NONE 11 6 36279 2423 1141DH+ECDH+PSK+RSA_CERT_OPT 19 14 84896 39513 2873DH+ECDH+PSK+RSA_CERT_REQ 16 11 87809 43435 2722

MbedTLS 2.16.1 50DH+ECDH+PSK+RSA_CERT_NONE 12 2 27811 531 545DH+ECDH+PSK+RSA_CERT_OPT 20 6 34236 3108 677DH+ECDH+PSK+RSA_CERT_REQ 17 5 32389 2755 658

NSS 3.46 100 DH+ECDH+RSA_DISC 10 5 21040 465 445

OpenSSL 1.1.1b 10DH+ECDH+PSK+RSA_CERT_NONE 14 7 36258 4119 303DH+ECDH+PSK+RSA_CERT_OPT 22 14 49467 9003 404DH+ECDH+PSK+RSA_CERT_REQ 19 10 41638 4359 338

PionDTLS 100

ECDH_CERT_NONE 66 37 70886 25920 1842ECDH_CERT_OPT 66 37 113508 68792 3067ECDH_CERT_REQ 66 33 94384 50767 2523PSK 14 7 21303 1859 503

Scandiumold 100∗ECDH_CERT_NONE_DISC 30 13 36927 7144 2518ECDH_CERT_OPT_DISC 45 21 45087 7006 2833ECDH_CERT_REQ_DISC 31 13 35404 3519 2243PSK 16 9 22646 883 1656

Scandiumnew 100∗ECDH_CERT_NONE 13 7 25548 2394 1607ECDH_CERT_OPT 17 11 27352 2033 1693ECDH_CERT_REQ 15 8 27233 2804 1718PSK 13 7 22983 1352 1621

TinyDTLSC 100ECDH_CERT_NONE 25 13 30696 2292 1162ECDH_CERT_REQ 30 23 35747 5111 1367PSK 25 15 27148 2713 1065

TinyDTLSE 100ECDH_CERT_NONE 22 12 56697 3209 1872ECDH_CERT_REQ 27 14 29897 1746 981PSK 22 11 24403 2728 707

WolfSSL 4.0.0 80∗ DH+ECDH+RSA_CERT_REQ 24 16 45402 8392 1851PSK 10 5 21611 584 656

the rule is GnuTLS 3.6.7, which competes with PionDTLSfor the highest number of tests, yet has relatively few states.We found that conformance testing using Wp-based methodsgenerally struggled with this implementation. A central acti-vity of Wp-based methods is to find sequences of inputs thatuniquely identify the different states in the Mealy machine.GnuTLS is designed to provide minimally informative outputto inputs that deviate from the happy flow: in most cases, theimplementation simply discards such inputs and stays silent(this can be seen in e.g., Fig. 3). As a consequence, the inputsequence which uniquely identifies a state can be very hard

to find, and can even be too long to be discovered duringlearning or conformance testing.

Learning time. Model learning experiments completedwithin one day on average, except for four implementations.Among these, PionDTLS and Scandium take considerably lon-ger due to large models (66 states for PionDTLS). Scandiumand GnuTLS take longer due to high response timeout values,motivated by very long processing times for messages such asClientHello (400 and 200 msecs respectively). This highlightsthe importance of message-specific timeouts, as suggested inSection 5.3.

Figure 3: Model of a GnuTLS 3.6.7 server with client certificate authentication optional. Blue edges capture the flows of regularhandshakes: dashed and dashed-dotted edges indicate the handshake expected when client certificate authentication is required,respectively when it is disabled. A dotted brown edge indicates a transition leading to a handshake restart.

7 Analysis of the Resulting State Machines

This section provides an analysis of the models against thespecification. We first give an overview of a DTLS state ma-chine, using the model learned for GnuTLS as an example.We explain the strategies employed to identify non-compliantbehaviors using the learned models. We then outline the non-compliant behaviors observed in the tested libraries. Finally,we present library-specific findings and vulnerabilities, inclu-ding the client authentication bypass in JSSE.

7.1 Description of a GnuTLS State Machine

Displaying models is challenging due to the large number ofinputs and states. We therefore prune the models via the fol-lowing strategies. We first use the Other input as replacementfor inputs not captured in a visible transition which lead to thesame state and output. Inputs and outputs are then replaced bytheir corresponding shorthands shown in Table 1. Finally, weplace transitions connecting the same states on single edges.Due to page limitations, this section only includes models for

GnuTLS 3.6.7, JSSE 12.0.2 and PionDTLS. All other modelscan be accessed via the learning setup’s website.

Figure 3 shows a model generated for the GnuTLS 3.6.7 li-brary and can be interpreted as follows. The server starts fromthe initial state, which is always state 0 on the state machine.On receiving ClientHello(PSK) it generates HelloVerify-Request and transitions to state 2. In response to a secondClientHello(PSK), it generates the messages ServerHello andServerHelloDone and transitions to state 3. Continuing thePSK handshake flow, on receiving ClientKeyExchange(PSK),ChangeCipherSpec and Finished, the server generates No-Resp (i.e., nothing) for the first two messages, and Change-CipherSpec and Finished for the third. In this interaction, theserver traverses the states 4 and 5, ending in 6.

The GnuTLS server was configured to use PSK- and RSA-based cipher suites. This is reflected in the model’s inputalphabet, which includes ClientHello and ClientKeyExchangefor both PSK and RSA. Client certificate authentication wasset to optional. In this situation, the server makes a client cer-tificate request, as indicated by the CertReq label on the edgefrom state 2 to state 7 in Fig. 3. The server does not require

client certificates, hence handshakes can be completed evenif the client chooses to send an EmptyCertificate by followingstates 0, 2, 7, 11, 4, 5 and 6; or no certificate at all by followingstates 0, 2, 7, 4, 5 and 6. Finally, if the client authenticateswith a Certificate message, the handshake traverses states 0, 2,7, 9, 10, 4, 5 and 6. Note that client certificate authenticationis implicitly disabled for cipher suites which do not supportit, such as PSK-based ones.

Besides states traversed by handshake flows, the modelcontains three other states: states 1, 8 and 12. State 1 is asink state, which is a state the model cannot transition out of.States 8 and 12 are superfluous states, since they are not ne-cessary for implementation correctness. They are a byproductof the implementation allowing handshake restarts, which arepossible from these states by transitions to state 2.

7.2 Identifying Irregular Behaviors

To identify potentially vulnerable behaviors using learnedmodels, we employ the following strategies.

First, we inspect models for irregular handshake flows (ir-regular handshakes for short). These are flows that lead tohandshake completion, indicated by a successfully transmit-ted Finished from the server, but may omit, repeat or changethe order of handshake messages, relative to regular flowspermitted by the specification. To aid analysis of larger mo-dels (such as those of JSSE or PionDTLS) we developed ascript to automatically remove states from which a hands-hake cannot be completed (i.e., it is no longer possible toreceive a Finished from the server). On the reduced models,handshake-completing flows can be identified much more ea-sily; this is showcased by Figs. 4 and 5. Using this approach,we uncovered bugs like early Finished, wherein a handshakeis completed by omitting the ChangeCipherSpec message.We refer to Sections 7.4 to 7.6 for descriptions of such bugsfor JSSE, Scandium and PionDTLS. Note that the script usedto reduce models comes packaged with our learning setup.

Second, we look for outputs from the server which do notconform to the specification. Of particular interest are irre-gular ServerHello responses, which are not part of irregularhandshakes (otherwise the flows would have been detectedand analyzed by our first strategy). We investigate whethera handshake may be completed using these responses. Tothat end, we probe the SUT’s reaction after such responsesto manually-crafted messages (typically ClientKeyExchange,ChangeCipherSpec and Finished), whose message sequen-ce/epoch numbers differ from what our MAPPER generates.Doing so, we were able to complete handshakes in TinyDTLSusing invalid epoch numbers; see Section 7.8. Also of interestare Alert outputs, as they shed light on how the system pro-cesses unexpected inputs. For example, Alert(DecryptError)suggests the SUT is not able to decrypt a message. Hence,Alert(DecryptError) is only expected as a response to an en-crypted message, and not to an unencrypted message, as was

Table 4: Summary of irregular behaviors detected in the testedlibraries. The message_seq column summarizes the correctusage of these numbers. 7 indicates that the implementationfinished the handshake with an invalid message_seq. Thethird column summarizes the cookie computation correctness.The last column depicts whether implementations correctlyvalidate the handshake message sequence.

LibraryValidation of Cookie Messagemessage_seq comp. order

numbers verification

GnuTLS 7 7 3JSSE 9.0.4 3 3 3JSSE 12.0.2 3 3 7MbedTLS 7 7 3NSS 3 7 3OpenSSL 3 7 3PionDTLS 3 3 7

Scandiumold 7 3 7Scandiumnew 7 3 3TinyDTLS 7 3 3WolfSSL 7 3 3

the case for TinyDTLS; see Section 7.8.Finally, we inspect the code exercised by irregular beha-

viors identified by the first two strategies in order to assesswhether they can result in further flaws. Such flaws can bemore severe than the initial irregularity suggests. As an exam-ple, the non-conforming Alert(DecryptError) in TinyDTLSled us to discover loss of reliability in the face of reorde-ring. Investigation can also reveal bugs not directly relatedto the behavior inspected, which, however, exercise roughlythe same portion of code. Such was the case for PionDTLS,where investigating an early Finished bug led to the discoveryof premature processing of application data; see Section 7.6.

7.3 General Behavior Patterns

Several conforming and non-conforming behavior patternsemerged while analyzing the learned models. Table 4 summa-rizes the irregular behaviors and the affected implementations.Handshake with invalid message_seq numbers. ManyDTLS server implementations allow for creating new associa-tions even when having an already established connection [36,Section 4.2.8]. This process involves performing a new Client-Hello–ServerHello exchange in the middle of an already star-ted or finished handshake, and results in agreeing on a newcipher suite and key material. The motivation behind this be-havior is to support clients that want to re-establish a newconnection after loosing one (e.g., after a reboot). Accordingto the DTLS specification [36, Section 4.2.2], every Client-Hello starting a new handshake must have message_seq =0. Every following handshake message has to increase the

Figure 4: Model of a JSSE 12.0.2 server with client certificate authentication required. Blue edges capture the happy flow,dotted red a handshake with an unauthenticated ClientKeyExchange message, dashed-dotted red a handshake without certificatemessages, dashed red a handshake without CertificateVerify.

message_seq number by one.3

In five of the tested implementations, it was possible tostart a DTLS handshake with a higher message_seq number.It was also possible to identify these implementations from thelearned models. For example, in the GnuTLS model (Fig. 3),we were able to detect such an invalid behavior by followingthe transitions looping back to state 2.Non-conforming cookie computation. Upon receiving aClientHello message, the server computes a stateless cookieand sends it via HelloVerifyRequest. The server expects thecookie to be replayed in the subsequent ClientHello message.According to the specification, the replayed ClientHello mes-sage must contain the same parameters as the first one (e.g.,supported cipher suites) [36, Section 4.2.1]. For this purpose,the server should use the initial ClientHello parameters tocompute the cookie value.

In our evaluation, we could observe four implementationsincorrectly computing the cookie value, resulting in incorrectvalidation of replayed ClientHello messages. Such a hands-hake is also captured in Fig. 3, where an RSA handshake canbe completed even if the first message was ClientHello(PSK).An exceptional case is NSS, which omits the cookie exchangestep altogether, in discord with the specification’s recommen-dation.Handshake with invalid order of messages. The most con-

3As mentioned in Section 2, DTLS also defines explicit sequence numbersin DTLS records. In contrast to message_seq numbers located in handshakemessages, an implementation can accept a DTLS record with a sequencenumber that was increased by more than one. This allows for accepting DTLSrecords after losing previous UDP packets.

sequential divergent behaviors are handshakes where invalidmessage sequences lead to handshake completion. These be-haviors may have severe security implications. We found thatJSSE, PionDTLS, and Scandiumold do not correctly verifythe DTLS handshake message sequence in their internal statemachines. Below we discuss these bugs and their implicati-ons.

7.4 Bypassing Client Authentication in JSSEFigure 4 depicts the hypothesis model generated for JSSE12.0.2 using one RSA-based cipher suite after two days oflearning. The model was obtained by erasing all states fromwhich a handshake could no longer be completed. The JSSEserver was configured to require client authentication.

The model depicts a correctly completed handshake, whichis marked with blue edges and follows states 0, 2, 4, 11, 12,3, 9, and 10. This flow includes Certificate and Certificate-Verify messages correctly sent by the client to authenticate tothe server. However, even though the server required clientauthentication, we were able to complete DTLS handshakeswithout sending Certificate or CertificateVerify messages. Theinvalid handshakes are captured in red and allow a clientto bypass client authentication. Our analysis revealed thatversions 11, 12 and 13 of Oracle and OpenJDK Java areaffected for all key exchange algorithms. Previous versionsare not affected by this issue.Unauthenticated ClientKeyExchange. We start the descrip-tion of JSSE vulnerabilities with a slightly modified happyflow, which follows states 0, 2, 4, 11, 5, 3, 9 and 10, and traver-

ses dotted red edges on the model. In this flow, the client sendsa CertificateVerify message before the ClientKeyExchange.This implies that the ClientKeyExchange message is not au-thenticated with the client certificate.

Being able to finalize such a DTLS handshake does notdirectly result in a critical vulnerability. If the client behavescorrectly and sends messages in the correct order, an attackercannot modify the ClientKeyExchange message or the mes-sage order because all the handshake messages are protectedby the Finished message. Still, this bug shows a first invalidbehavior, and scratches on the surface of other invalid ones.Certificate-less client authentication. The second vulnera-bility is marked with dashed-dotted red edges in Fig. 4. TheDTLS handshake starts with four ordinary flights of messages.In the fourth flight, the server requests client authenticationby sending a CertificateRequest message. However, the clientignores this message and continues the handshake with Client-KeyExchange, ChangeCipherSpec, and Finished messages,without sending Certificate and CertificateVerify. The serverresponds to the last message with ChangeCipherSpec andFinished, thus completing handshake. This allows the clientto completely bypass client authentication and proceed withsending application data.

Note that the handshake process remains completely trans-parent to the server, as long as the server does not try tomanually inspect the certificate of the peer after completingthe handshake. Since the client does not send any certificate,the certificate in the internal JSSE context is null. If the ser-ver attempts to evaluate the certificate data (e.g., to accessthe subject name or certificate issuer fields), this will resultin an SSLPeerUnverifiedException and most likely interruptthe authentication process. The next finding bypasses thisconstraint as well.CertificateVerify-less client authentications. The third vul-nerability follows red dashed edges in Fig. 4 and partiallyrelies on the behavior described above. It allows an attackerto authenticate as an arbitrary user without the possession ofthe private key. The only prerequisite is that the attacker isin possession of a valid client certificate. This requirement isin most cases trivially achieved as certificates are usually notconsidered private and can be found in public repositories orprovided in frameworks like Certificate Transparency.

As already visualized on the model, after receiving thesecond server message flight, the attacker can send a Client-KeyExchange message, thus transitioning from 4 to 7. Insteadof directly sending a ChangeCipherSpec message, we con-tinue with an out-of-order Certificate message. Finally, wesend ChangeCipherSpec and Finished. The server then re-sponds with ChangeCipherSpec and Finished, after which itcan accept an Application message encrypted under the esta-blished keys. Thus, the attacker is able to finalize the DTLShandshake without CertificateVerify, and thus without beingin possession of the certificate’s private key. The crucial diffe-rence in comparison to the previous vulnerability is that the

server accepts the certificate, and is able to correctly processits contents. Therefore, no SSLPeerUnverifiedException isthrown, and the application has no possibility to detect theinvalid client behavior.Attack rationale and state machine analysis. To under-stand the above described behaviors, we analyzed the JSSEstate machine implementation. The reason behind the vulne-rabilities is not intuitive. In general, it can be summarized inthe following processing properties. First, the server does notvalidate a proper message order. From the first bug, we canconclude that specific handshake messages can be sent in a dif-ferent order (e.g., ClientKeyExchange and CertificateVerify).Second, the server only partially validates the correctnessof received messages. For example, it validates whether thehandshake contains a ClientKeyExchange message, or it doesnot accept further ClientHello messages after a ServerHello-Done message has been sent. Third, and most importantly,the server does not verify the presence of critical messagesafter the handshake has been finalized. In particular, it doesnot check whether Certificate and CertificateVerify messageswere received after a CertificateRequest has been sent.

Our code analysis revealed that the JSSE implementa-tion always waits for at least ClientKeyExchange, Change-CipherSpec, and Finished messages. Messages arriving out-of-order can be cached. This explains why we could observeso many different paths leading to handshake completion inthe learned model.

Interestingly, the bugs affect the TLS implementation in asimilar way as well. Omitting the Certificate and Certificate-Verify messages also authenticates the client. Additionally,just removing the CertificateVerify message (while leavingthe Certificate message) also authenticates the client. Wewere able to reproduce the issues with Apache Tomcat 9.0.22,which was configured with JSSE and required client authenti-cation.4 We reported the vulnerabilities to the Oracle securityteam. They were assigned CVE-2020-2655 and patched withthe Oracle critical patch update in January 2020.

7.5 State Machine Bugs in ScandiumScandiumold produced some of the largest models. This isreflective of the fact that the implementation did not use aninternal state machine to validate the sequence of handshakemessages. Consequently, its model captures handshakes withinvalid sequences of messages. Reporting our findings promp-ted Scandium developers to update the implementation withstate machine validation (Scandiumnew). This update fixed allthe Scandium bugs reported in this paper. The update not onlyhelped to simplify the learned model (for a PSK configurationreducing the size from 16 to 13), but also enabled convergencefor ECDH configurations resulting in similarly small models.

4It is also possible to configure Apache Tomcat with an OpenSSL engine(https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html).This version was not affected.

Figure 5: Model of a PionDTLS server with client certificate authentication required. The model was reduced from 66 states to11 by retaining only states from which a handshake can be finalized. Dotted red indicates an early Finished handshake, dashedred a handshake with a delayed CertificateVerify message.

Models for the original and updated versions are availableonline. Below, we present findings for the original version.Early Finished. Scandium allows a handshake to be comple-ted without the client sending a ChangeCipherSpec message.The server then interprets all the upcoming messages as sentin plaintext. It still expects a valid Finished message withcorrect verify_data from the client to complete the handshake.Therefore, a man-in-the-middle attacker is not able to simplydrop ChangeCipherSpec and use a fabricated Finished mes-sage to decrypt the traffic. A valid verify_data would still berequired to complete the handshake. This is not possible tocompute without possessing the master secret or exploitingfurther bugs. However, this behavior shows fragility of theScandium state machine.

The early Finished message bug is remarkably similar tothe bug reported for JSSE 1.8.0_25 [13], and is related tothe attack described by Wagner and Schneier [44]. An attac-ker could exploit this behavior by injecting a backdoor intoa library which would force a DTLS client to skip Change-CipherSpec messages. The attacker could then observe plain-text connections established with any Scandium server.Multiple ChangeCipherSpec in a handshake. Scandiumcan complete handshakes wherein ChangeCipherSpec is fol-lowed by one or more ChangeCipherSpec messages and thenFinished. On each ChangeCipherSpec sent, the MAPPER in-crements the epoch used in follow-up messages. Thus, thesent Finished carries an epoch number for which a cipher hasnot been negotiated. The fact that Scandium completes hands-hakes in such a situation further showcases the looseness ofits implementation.Measurable improvements. After we reported the vulnera-bilities to the Scandium developers, they were able to simplifyScandium’s state machine significantly. Scandiumnew gene-

rates at most 17 states, whereas Scandiumold generates up to45 in a more restricted setting.

7.6 Severe Bugs in PionDTLS

Early Finished revisited. PionDTLS exhibits an early Fi-nished message bug which is similar to the one found inScandium. Obtained for a server requiring certificate authenti-cation, PionDTLS’s model (Fig. 5) captures three handshakesinstead of the one expected. The two additional handsha-kes are an early Finished handshake and a handshake witha ChangeCipherSpec message preceding CertificateVerify(where the CertificateVerify is sent encrypted). This latter bugclearly shows that PionDTLS does not correctly validate theordering of messages.Processing of unencrypted application data. During theanalysis of the previous bug, we noticed that PionDTLSfreely processed unencrypted application data delivered withepoch 0. This bug has severe consequences by allowing anattacker to inject arbitrary application data at any point once ahandshake has been completed. The bug was promptly fixedonce we reported our findings to the developers.HelloVerifyRequest retransmissions. PionDTLS occasio-nally responds to the first ClientHello message with multipleHelloVerifyRequest messages. This response is marked withHVR+ in Fig. 5. When investigating this behavior we foundthat PionDTLS will retransmit HelloVerifyRequest messa-ges until a timeout elapses or it receives the second Client-Hello. RFC 6347 advises against retransmitting HelloVerify-Request [36, p. 6], as doing so requires the server to keepstate, making it susceptible to Denial-of-Service attacks. Theretransmission also enables amplification attacks, wherein anattacker sends ClientHello messages to the server with the

IP address of a victim as the source address. As a result, theserver will then send its replies to the spoofed source address,thus flooding the victim with HelloVerifyRequest messages.

7.7 Invalid Handshake Start in GnuTLSIn GnuTLS 3.5.19, we detected a bug in the initial state;the implementation treated most messages as if they wereClientHello. In doing so, the server responded to them withHelloVerifyRequest and it transitioned to the next handshakestate. We reported the bug to the GnuTLS developers whowere able to reproduce and fix the issue.

7.8 Security Violations & Bugs in TinyDTLSInsecure renegotiation. After performing a DTLS hands-hake with a TinyDTLS server, we were able to use the esta-blished encrypted connection to perform the next handshake.This process is also called renegotiation and allows the clientto establish new keys for the given connection. However, itcan only be safely used if the ClientHello message contains arenegotiation indication extension and the server can processit [34]. Otherwise, the server may be vulnerable to an insecurerenegotiation attack [34]; see also CVE-2009-3555.

The ClientHello messages we used did not contain anyrenegotiation indication extension. Therefore, every renego-tiation attempt should have been rejected by the processingserver. However, this was not the case. TinyDTLS violatedRFC 5746 [34, Sect. 3.2] and was vulnerable to the insecurerenegotiation attack. The real exploitability of this behaviordepends on the application using the TinyDTLS library.Crashes on ChangeCipherSpec. In addition, we found thatin certain states TinyDTLSE crashes on receiving Change-CipherSpec. For example, it crashed on receiving this mes-sage in the initial state. The crashing behavior resulted in areduction of states compared to TinyDTLSC since crashinginputs predictably lead to a single sink state. The crash wasa result of a segmentation fault resulting from a null addressread. This bug is a rediscovery of CVE-2017-7243, which isstill unfixed in the master branch of the TinyDTLSE .From inconsistent alert to unreliable handshake protocol.By analyzing the learned model, we could observe frequentusage of Alert(DecryptError) messages. This alert is sent byTinyDTLS whenever it tries to decrypt a record (whether it isactually encrypted or not), and fails to find key material forthe epoch in its internal state. This behavior is in itself rat-her unproblematic, but TinyDTLS also invalidates the wholeconnection in such a case. This can result in connections brea-king unnecessarily when the ChangeCipherSpec and Finishedmessages are received out of order in a regular handshake.Handshake with invalid epoch numbers. The model forTinyDTLSC revealed that the server can perform the first twosteps of a handshake using ClientHello messages with epoch 1when no cipher for epoch 0 has yet been negotiated. Upon

further investigation, we were able to complete the hands-hake by sending ClientKeyExchange, ChangeCipherSpec andFinished having the same epochs as in a normal handshake(which are 0, 0 and 1, respectively). The handshake is clearlyinvalid and should not have been possible to complete.

7.9 Bugs in OpenSSLFinished treated as retransmission. After a successfulhandshake completion, the OpenSSL server treats retrans-mitted Finished messages incorrectly. OpenSSL responds toa newly computed and transmitted Finished message by re-sending the last flight (ChangeCipherSpec, Finished). TheFinished message received from the server has a different mes-sage sequence number and verify_data content. An adequateresponse would have been either to discard this message, orto send an alert and possibly terminate the connection.InternalError alerts. Alert(InternalError) is sent byOpenSSL in response to unexpected Finished messages. In-ternally, OpenSSL is processing the message and trying tocompute the verify_data for the Finished message. However,due to defensive programming, missing parameters in the ses-sion context are discovered, the processing of the message isstopped, and an Alert(InternalError) is returned. An appropri-ate response should have been an alert indicating the receiptof an out-of-order message. Alert(UnexpectedMessage) hasbeen designed for such purposes.

7.10 Observed Code PatternsWe can conclude that in our analysis we observed severalrepeating code patterns, which led to the bugs and vulnerabili-ties. Most importantly, most of the analyzed implementationsdo not use proper state machines. While they attempt to verifythe handshake protocol flow with simple checks in switch sta-tements, a complete message flow validation is missing. Thiswas, for example, observed by the analysis of the Scandiumimplementation, which was too liberal when it comes to themessage sequence verification; only other additional checksin the code prevented further security vulnerabilities. Onereason for missing state machines could be the fact the DTLSspecification [36] does not give a design for one. We believethat protocol standards should contain such designs and de-mand that implementations use them.

In the libraries implementing TLS and DTLS, we couldobserve that the code is re-used in both protocols. This meansthat similar vulnerabilities in one protocol implementation caninfluence the other. For example, we found the authenticationbypass in JSSE by analyzing the DTLS server implementation.However, our subsequent analysis revealed that the bug is alsoapplicable to TLS. We expect that similar behaviors will befound in the future.

Interestingly, both Scandium and PionDTLS include thesame early Finished message bug that was found in JSSE TLS

in 2015 [13]. While this again may be attributed to missingstate machine implementation, we believe that this bug isclosely related to an ambiguity, which is mentioned in [36].

As with TLS, the ChangeCipherSpec message isnot technically a handshake message [...]. This cre-ates a potential ambiguity because the order of theChangeCipherSpec cannot be established unambi-guously with respect to the handshake messages incase of message loss.

In DTLS up to version 1.2, this ambiguity has to be resolvedby hard-coding the expected ChangeCipherSpec message.In the recent DTLS 1.3 drafts [16], the problem has beenresolved by removing ChangeCipherSpec messages entirely.

8 Related Work

In this section, we give a brief summary of previous work onanalyses of DTLS and on state fuzzing of security protocols.

Due to the similarity with TLS, most of the attacks appli-cable to TLS are potentially applicable to DTLS protocolimplementations as well. This includes attacks like Heart-bleed [37], Bleichenbacher’s attack [7], or CBC padding ora-cle attacks [43]. One exception is the attack presented byAlFardan and Paterson in 2012, who adapted padding oracleattacks to DTLS by using novel DTLS side channels [1]. Theadaptation exploits subtle timing differences between pro-cessing packets with valid and invalid padding, amplified bythe processing of subsequent Heartbeat messages. The attackwas applicable to OpenSSL and GnuTLS. In 2013, the sameauthors extended their work to a powerful attack breakingboth TLS and DTLS – Lucky13 [2].

Van Drueten obtained some preliminary results on ana-lyzing DTLS implementations using protocol state fuzzing,from which this work branched off. His thesis [42] analy-zed OpenSSL and mbedTLS with a limited input alphabetand did not reveal any security vulnerabilities. De Ruiter andPoll [13] used protocol state fuzzing to analyze TLS imple-mentations and found several security bugs. In comparison,the models we learn are significantly larger, due to complexityin DTLS introduced by UDP, and our inclusion of several keyexchange algorithms and certificate settings. Also, as statedbefore, some of the bugs we found are only possible underparticular configurations or are specific to DTLS.

McMahon Stone et al. [28] extend state learning such thatit also captures time behavior and can operate also over an un-reliable communication medium. They then use the extensionto analyze implementations of the 802.11 4-Way Handshakein seven Wi-Fi routers. In dealing with non-determinism, ourwork employs some of the same strategies, such as checkingcounterexamples against a cache, or using majority voting.However, it can use a more efficient learning setup, as it doesnot have to deal with a lossy medium and resulting timeouts.Chalupar et al. [9] also had to address non-determinism of

the system, though this time it was not introduced by the me-dium but by the system itself. In their work, a simple majorityvoting system was sufficient to address these issues.

9 Conclusions and Future Work

We have presented the first protocol state fuzzing frameworkfor DTLS. As a basis, in particular for constructing a MAPPER,we have developed a test framework for DTLS, based onTLS-Attacker. The MAPPER and test framework implementDTLS specifics including explicit sequence number, supportfor cookie management, and epoch numbers. In this paper,we focused on discovering state machine bugs, triggered bysequences of valid handshake messages. We did not exer-cise reordering and fragmentation. Nevertheless, we used ourplatform to generate models of thirteen widely used DTLSserver implementations, and were able to find critical securityvulnerabilities and implementation flaws in them.

There are several directions for future work: (i) The analy-sis can also explore Record Layer functionality such as frag-mentation and reordering, by adding a strategy for sendingreordered and fragmented records. Since these functionali-ties should be handled transparently by the Record Layer, wecan directly use our already learned models as specifications.(ii) Our learned models can be used to support systematic tes-ting with invalid input messages, as is done in protocol fuzzers.(iii) Our analysis of learned models was performed manually;automation using model checking techniques should be inves-tigated, for example, by following the methodology presentedin work for TCP [18] or SSH [19].

Acknowledgements

We would like to thank Jörg Schwenk, our shepherd KennethPaterson, and the anonymous reviewers for many insightfulcomments. We also thank Niels van Drueten for his contribu-tion to an initial version of the test framework.

The research was established at the Lorentz Center works-hop on Systematic Analysis of Security Protocol Implementa-tions. It was partially funded by the Swedish Foundation forStrategic Research (SSF) through the aSSIsT project, the Swe-dish Research Council, and the Deutsche Forschungsgemein-schaft (DFG, German Research Foundation) under Germany’sExcellence Strategy - EXC 2092 CASA - 390781972.

References

[1] Nadhem AlFardan and Kenneth G. Paterson. Plaintext-recovery attacks against Datagram TLS. In Network andDistributed System Security Symposium, NDSS 2012,2012.

[2] Nadhem J. AlFardan and Kenneth G. Paterson. Luckythirteen: Breaking the TLS and DTLS record protocols.

In 2013 IEEE Symposium on Security and Privacy, pa-ges 526–540. IEEE, 2013.

[3] Dana Angluin. Learning regular sets from queriesand counterexamples. Information and Computation,75(2):87–106, 1987.

[4] Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky,Nadia Heninger, Maik Dankel, Jens Steube, Luke Va-lenta, David Adrian, J. Alex Halderman, Viktor Dukho-vni, Emilia Käsper, Shaanan Cohney, Susanne Engels,Christof Paar, and Yuval Shavitt. DROWN: BreakingTLS using SSLv2. In 25th USENIX Security Symposium,USENIX Security 16, pages 689–706, August 2016.

[5] Benjamin Beurdouche, Karthikeyan Bhargavan, AntoineDelignat-Lavaud, Cédric Fournet, Markulf Kohlweiss,Alfredo Pironti, Pierre-Yves Strub, and Jean Karim Zin-zindohoue. A messy state of the union: Taming thecomposite state machines of TLS. Commun. ACM,60(2):99–107, February 2017.

[6] Benjamin Beurdouche, Antoine Delignat-Lavaud, Na-dim Kobeissi, Alfredo Pironti, and Karthikeyan Bharga-van. FlexTLS: A tool for testing TLS implementations.In 9th USENIX Workshop on Offensive Technologies,WOOT 15. USENIX Association, August 2015.

[7] Daniel Bleichenbacher. Chosen ciphertext attacksagainst protocols based on the RSA encryption stan-dard PKCS #1. In Advances in Cryptology - CRYPTO

’98, volume 1462 of LNCS. Springer, Berlin / Heidelberg,1998.

[8] Botan: Crypto and TLS for C++11, 2019.

[9] Georg Chalupar, Stefan Peherstorfer, Erik Poll, and Joeride Ruiter. Automated reverse engineering using Lego R©.In 8th USENIX Workshop on Offensive Technologies,WOOT 14. USENIX Association, August 2014.

[10] Chia Yuan Cho, Domagoj Babic, Eui Chul Richard Shin,and Dawn Song. Inference and analysis of formal mo-dels of botnet command and control protocols. In Pro-ceedings of the 17th ACM Conference on Computer andCommunications Security, CCS 2010, pages 426–439.ACM, October 2010.

[11] Tsun S. Chow. Testing software design modeled byfinite-state machines. IEEE Trans. Soft. Eng., 4(3):178–187, May 1978. Special collection based on COMPSAC.

[12] Lesly-Ann Daniel, Erik Poll, and Joeri de Ruiter. In-ferring OpenVPN state machines using protocol statefuzzing. In IEEE European Symposium on Securityand Privacy (EuroS&P) Workshops, pages 11–19. IEEE,April 2018.

[13] Joeri de Ruiter and Erik Poll. Protocol state fuzzing ofTLS implementations. In 24th USENIX Security Sym-posium, pages 193–206. USENIX Association, August2015.

[14] T. Dierks and Eric Rescorla. The transport layer security(TLS) protocol version 1.1. RFC 4346, April 2006.

[15] T. Dierks and Eric Rescorla. The transport layer securityTLS protocol version 1.2. RFC 5246, August 2008.

[16] N. Modadugu E. Rescorla, H. Tschofenig. The datagramtransport layer security (DTLS) protocol version 1.3 -draft-34, July 2018.

[17] P. Eronen and H. Tschofenig. Pre-shared key ciphers-uites for transport layer security (TLS). RFC 4279,December 2005.

[18] Paul Fiterau-Brostean, Ramon Janssen, and Frits W.Vaandrager. Combining model learning and modelchecking to analyze TCP implementations. In Compu-ter Aided Verification - 28th International Conference,CAV 2016, Proceedings, Part II, volume 9780 of LNCS,pages 454–471. Springer, 2016.

[19] Paul Fiterau-Brostean, Toon Lenaerts, Joeri de Ruiter,Erik Poll, Frits W. Vaandrager, and Patrick Verleg. Mo-del learning and model checking of SSH implementati-ons. In Proceedings of the 24th ACM SIGSOFT Interna-tional SPIN Symposium on Model Checking of Software,SPIN 2017, pages 142–151. ACM, 2017.

[20] Susumu Fujiwara, Gregor von Bochmann, Ferhat Khen-dek, Mokhtar Amalou, and Abderrazak Ghedamsi. Testselection based on finite state models. IEEE Trans. Soft.Eng., 17(6):591–603, June 1991.

[21] Malte Isberner. Foundations of Active Automata Lear-ning: An Algorithmic Perspective. PhD thesis, TechnicalUniversity Dortmund, Germany, 2015.

[22] Malte Isberner, Falk Howar, and Bernhard Steffen. TheTTT algorithm: A redundancy-free approach to activeautomata learning. In Runtime Verification: 5th Interna-tional Conference, RV 2014, Proceedings, volume 8734of LNCS, pages 307–322. Springer, September 2014.

[23] Malte Isberner, Falk Howar, and Bernhard Steffen. Theopen-source LearnLib - A framework for active auto-mata learning. In Computer Aided Verification - 27thInternational Conference, CAV, volume 9206 of LNCS,pages 487–495. Springer, 2015.

[24] Hubert Kario. tlsfuzzer, 2018.

[25] David Lee and Mihalis Yannakakis. Principles and met-hods of testing finite state machines—a survey. Procee-dings of the IEEE, 84(8):1090–1123, 1996.

[26] Knud Lasse Lueth. State of the IoT 2018: Number ofIoT devices now at 7B — market accelerating, August2018.

[27] matrixSSL. Compact Embedded SSL/TLS stack, 2019.

[28] Chris McMahon Stone, Tom Chothia, and Joeri de Rui-ter. Extending automated protocol state learning for the802.11 4-way handshake. In Computer Security, volume11098 of LNCS, pages 325–345, Cham, August 2018.Springer International Publishing.

[29] Nagendra Modadugu and Eric Rescorla. The design andimplementation of Datagram TLS. In Proceedings of theNetwork and Distributed System Security Symposium,NDSS 2004, 2004.

[30] Bodo Möller, Thai Duong, and Krzysztof Kotowicz.This POODLE bites: exploiting the SSL 3.0 fallback,2014.

[31] Thomas Pornin. BoarSSL, 2017.

[32] Harald Raffelt, Maik Merten, Bernhard Steffen, and Ti-ziana Margaria. Dynamic testing via automata learning.STTT, 11(4):307–324, 2009.

[33] Abdullah Rasool, Greg Alpár, and Joeri de Ruiter.State machine inference of QUIC. arXiv preprintarXiv:1903.04384, 2019.

[34] E. Rescorla, M. Ray, S. Dispensa, and N. Oskov. Trans-port layer security (TLS) renegotiation indication exten-sion. RFC 5746, February 2010.

[35] Eric Rescorla and Nagendra Modadugu. Datagram trans-port layer security. RFC 4347, April 2006.

[36] Eric Rescorla and Nagendra Modadugu. Datagram trans-port layer security version 1.2. RFC 6347, January 2012.

[37] Riku, Antti, Matti, and Neel Mehta. Heartbleed, CVE-2014-0160, 2015.

[38] Zach Shelby, Klaus Hartke, and Carsten Bormann. Theconstrained application protocol (CoAP). RFC 7252,June 2014.

[39] Juraj Somorovsky. Systematic fuzzing and testing ofTLS libraries. In Proceedings of the 2016 ACM SIGSACConference on Computer and Communications Security,CCS ’16, pages 1492–1504, New York, NY, USA, 2016.ACM.

[40] Martin Tappler, Bernhard K. Aichernig, and RoderickBloem. Model-based testing IoT communication viaactive automata learning. In Software Testing, Verifi-cation and Validation, (ICST) 2017 IEEE InternationalConference on, pages 276–287. IEEE Computer Society,March 2017.

[41] Frits W. Vaandrager. Model learning. Commun. ACM,60(2):86–95, 2017.

[42] Niels van Drueten. Security analysis of DTLS 1.2 im-plementations. Bachelor thesis, Radboud University,Nijmegen, The Netherlands, 2019.

[43] Serge Vaudenay. Security flaws induced by CBC pad-ding - applications to SSL, IPSEC, WTLS ... In Advan-ces in Cryptology - EUROCRYPT 2002, volume 2332of LNCS. Springer, Berlin / Heidelberg, April 2002.

[44] David Wagner and Bruce Schneier. Analysis of the SSL3.0 protocol. In Proceedings of the 2nd USENIX Works-hop on Electronic Commerce, pages 29–40, Berkeley,CA, USA, 1996. USENIX Association.