Benjamin Beurdouche

Antoine Delignat-Lavaud

Nadim Kobeissi

Alfredo Pironti

Karthikeyan Bhargavan

FLEXTLS A Tool for Testing TLS Implementations

Keywords: Transport Layer Security, Cryptographic Protocols, Attacks, Protocol Testing

We present FLEXTLS, a tool for rapidly prototyping and testing implementations of the Transport Layer Security (TLS) protocol. FLEXTLS is built upon MITLS, a verified implementation of TLS, and hence protocol scenarios written in FLEXTLS can benefit from robust libraries for messaging and cryptography. Conversely, attack scripts in FLEXTLS can be used to evaluate and communicate the impact of new protocol vulnerabilities.

FLEXTLS was used to discover recent attacks on TLS implementations, such as SKIP and FREAK, as well as to program the first proof-of-concept demos for FREAK and Logjam. It is also being used to experiment with proposed designs of the upcoming version 1.3 of TLS. Our goal is to create a common platform where protocol analysts and practitioners can easily test TLS implementations and share protocol designs, attacks or proofs.

Introduction

Transport Layer Security (TLS) is used to establish secure channels for a wide variety of applications, including HTTPS websites, encrypted email, VPNs and Wi-Fi networks. As such, the TLS protocol and its implementations have been carefully scrutinized and formally analyzed [START_REF] Krawczyk | On the security of the TLS protocol: A systematic analysis[END_REF][START_REF] Bhargavan | Proving the TLS handshake secure (as it is)[END_REF]. Still, protocol flaws and implementation errors keep being discovered at a steady rate [START_REF] Kikuchi | How I discovered CCS Injection Vulnerability[END_REF][START_REF] Beurdouche | A messy state of the union: Taming the composite state machines of TLS[END_REF][START_REF] Adrian | Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice[END_REF], which forces browsers and other TLS software vendors to release multiple security patches each year. Attacks against TLS are also increasing in complexity: the recent Triple Handshake attack [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF] requires a man-in-the-middle that juggles with no less than 20 protocol messages over four connections to perform a full exploit. Assessing the impact of such vulnerabilities can be challenging, both for formalists and practitioners, because of the large effort needed to implement them from scratch, or to modify an existing implementation in order to test potentially affected libraries.

In this paper, we present FLEXTLS, a tool for instrumenting arbitrary sequences of TLS messages. FLEXTLS was originally created in order to write proofs of concept of complex transport layer attacks such as Triple Handshake or the early CCS attack against OpenSSL [START_REF] Kikuchi | How I discovered CCS Injection Vulnerability[END_REF]. It has been further extended to support automatic execution of multiple scripted scenarios: our tool has the ability to connect (either as a client or as a server) to a peer and send a set of programmatically generated sequences of TLS messages. This feature has been leveraged in order to test the robustness of various implementations of the TLS state machine against unexpected sequences of protocol messages [START_REF] Beurdouche | A messy state of the union: Taming the composite state machines of TLS[END_REF]. This effort led to the discovery of several new high-impact security vulnerabilities in a number of TLS implementations, including the FREAK attack.

Partly in response to these attacks, the IETF is considering several new extensions [START_REF] Bhargavan | Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension[END_REF][START_REF] Gillmor | Negotiated finite field Diffie-Hellman ephemeral parameters for TLS[END_REF][START_REF] Langley | Transport layer security (TLS) false start[END_REF], as well as a completely new revision of the protocol (TLS 1.3 [START_REF] Rescorla | The Transport Layer Security (TLS) Protocol Version 1.3[END_REF]) that introduces new message flows and handshake modes. Typically, academic scrutiny of new protocols lags behind standardization, because developing models and proofs is time consuming and the effort can only be justified for stable protocols. We demonstrate that FLEXTLS can be used to quickly implement and evaluate various new proposals, thus allowing us to contribute feedback early in the standardization process. FLEXTLS is built using MITLS [START_REF] Bhargavan | Implementing TLS with verified cryptographic security[END_REF], a verified reference implementation of TLS. In particular, it reuses the MITLS modules for message formatting and TLS-specific cryptographic constructions, but wraps them within modules that are more flexible and allow the core protocol mechanisms to be used in new and unexpected ways. Although the core MITLS modules have been proved correct, we make no formal claims about the correctness of FLEXTLS. We note that extending MITLS with new protocol features requires a significant verification effort to preserve its security proof. FLEXTLS aids, however, this process by enabling the incremental development and systematic testing of extensions to MITLS before they are integrated into the verified codebase.

The FLEXTLS tool and all the code examples discussed in this paper can be downloaded as part of the MITLS distribution at: miTLS.org

FLEXTLS Design and API

FLEXTLS is distributed as a .NET library written in the F# functional programming language. Using this library, users may write short scripts in any .NET language to implement specific TLS scenarios. FLEXTLS reuses the messaging and cryptographic modules of MITLS, a verified reference implementation of TLS. MITLS itself provides a strict application programming interface (API) that guarantees that messages are sent and received only in the order prescribed by the protocol standard. In contast, FLEXTLS has been designed to offer a flexible API that allows users to easily experiment with new message sequences and new protocol scenarios. In particular, the API provides the following features:

• A high-level messaging API with sensible defaults.

• A functional state-passing style to manage the states of multiple concurrent connections.

• Support for arbitrary reordering, fragmentation and tampering of protocol messages.

• Safe extensions to MITLS, enabling incremental verification of new protocol features.

Figure 1 depicts the architecture of FLEXTLS. On the left is the public API for FLEXTLS, with one module for each protocol message (e.g. ClientHello), and one module for each sub-protocol of TLS (e.g. Handshake). These modules are implemented by directly calling the core messaging and cryptographic modules of MITLS (shown on the right).

Each FLEXTLS module exposes an interface for sending and receiving messages, so that an application can control protocol execution at different levels of abstraction. For example, a user application can either use the high-level ClientHello interface to create a correctlyformatted hello message, or it can directly inject raw bytes into a handshake message via the low level Handshake interface. For the most part, applications will use the high-level interface, and so users can ignore message formats and cryptographic computations and focus only on the fields that they wish to explicitly modify. The FLEXTLS functions will then try to use sensible (customizable) defaults when processing messages, even when messages are sent or received out of order. We rely on F# function overloading and optional parameters to provide different variants of these functions in a small and simple API.

Each FLEXTLS module is written in a functional statepassing style, which means that each messaging function takes an input state and returns an output state and does not maintain or modify any internal state; the only side-effects in this code are the sending and receiving of TCP messages. This differs drastically from other TLS libraries like OpenSSL, where any function may implictly modify the connection state (and other global state), making it difficult to reorder protocol messages or revert a connection to an earlier state. The stateless and functional style of FLEXTLS ensures that different connection states do not interfere with each other. Hence, scripts can start any number of connections as clients and servers, poke into their states to copy session parameters from one connection to another, reset a connection to an earlier state, and throw away partial connection states when done. For example, this API enables us to easily implement manin-the-middle (MITM) scenarios, which can prove quite tedious with classic stateful TLS libraries.

A common source of frustration with experimental protocol toolkits is that they often crash or provide inconsistent results. FLEXTLS gains its robustness from three sources: By programming FLEXTLS in a strongly typed language like F#, we avoid memory safety errors such as buffer overruns. By further using a purely functional style with no internal state, we prevent runtime errors due to concurrent state modification. Finally, FLEXTLS inherits the formal proofs of functional correctness and security for the MITLS building blocks that it uses, such as message encoding, decoding, and protocol-specific cryptographic constructions. FLEXTLS provides a new flexible interface to the internals of MITLS, bypassing the strict state machine of MITLS, but it does not otherwise rely on any changes to the verified codebase. Instead, FLEXTLS offers a convenient way to extend MITLS with new experimental features that can first be tested and verified in FLEXTLS before being integrated into MITLS.

In the rest of this section, we outline the FLEXTLS messaging API and illustrate it with an example.

TLS Messaging API The TLS protocol [START_REF] Dierks | The Transport Layer Security (TLS) Protocol Version 1.2[END_REF] supports several key exchange mechanisms, client and server authentication mechanisms, and transport-layer encryption schemes. Figure 2 depicts a typical TLS connection, here using an Ephemeral Diffie-Hellman key exchange (DHE or ECDHE), where both client and server are authenticated with X.509 certificates. The dotted lines refer to encrypted messages, whereas messages on solid lines are in the clear.

Each connection begins with a sequence of handshake messages, followed by encrypted application data in both directions, and finally closure alerts to terminate the con- nection. In the handshake, the client and server first send Hello messages to exchange nonces and to negotiate which ciphersuite they will use. Then they exchange certificates and key exchange messages and authenticate these messages by signing them. The session master secret (ms) and connection keys are derived from the key exchange messages and fresh nonces. The change cipher spec (CCS) messages signal the beginning of encryption in both directions. The handshake completes when both the client and server send Finished messages containing MACs of the handshake transcript (log) with the master secret. Thereafter, they can safely exchange (encrypted) application data until the connection is closed.

FLEXTLS offers modules for constructing and parsing each of these messages at different levels of abstraction. For example, each handshake message can be processed as a specific protocol message, a generic handshake message, a TLS record, or a TCP packet.

Every module offers a set of receive(), prepare() and send() functions. We take the set of overloaded ServerHello.send() functions as an example to describe the API design.

Each TLS connection is identified by a state variable (of type state) that stores the network socket and the security context which is composed of session information (e.g. encryption algorithms), keys and record level state (e.g. sequence numbers and initialization vectors). Furthermore, the completion of a TLS handshake sets up a next security context (of type nextSecurityContext) that represents the new session established by this handshake; the keys in this context will be used to protect application data and future handshakes. In particular, the session information (of type SessionInfo) contains the security parameters of this new security context.

Figure 2 Mutually authenticated TLS-DHE connection

Client C Server S ClientHello(cr, [CS 1 , CS 2 , . . .]) ServerHello(sr, sid , CS k ) ServerCertificate(cert S , pk S ) ServerKeyExchange(sign(sk S , kex S )) CertificateRequest ServerHelloDone ClientCertificate(cert C , pk C ) ClientKeyExchange(kex C ) log 1 log 1 CertificateVerify(sign(sk C , log 1 )) log 2 log 2 ClientCCS ClientFinished(verifydata(ms, log 2 )) log 3 log 3 ServerCCS ServerFinished(verifydata(ms, log 3 )) . . . Data i Data j . . . CloseNotifyAlert CloseNotifyAlert
The ServerHello module offers the following function that can be used to send a ServerHello message at any time, regardless of the current state of the handshake:

ServerHello.send( st:state, si:SessionInfo, extL:list<serverExtension>, ?fp:fragmentationPolicy ) : state ⇤ FServerHello It takes the current connection state, the session information of the next security context, a list of server protocol extensions, and an optional fragmentation policy on the message that can specify how to split the generated message across TLS records (by default, records are fragmented as little as possible).

The function returns two values: a new connection state and the message it just sent. The caller now has access to both the old and new connection state in which to send further messages, or repeat the ServerHello. Moreover, the user can read and tamper with the message and send it on another connection.

The ServerHello.send() function also has a more elaborate version, with additional parameters:

ServerHello.send( st:state, fch:FClientHello, ?nsc:nextSecurityContext, ?fsh:FServerHello, ?cfg:config, ?fp:fragmentationPolicy ) : state ⇤ nextSecurityContext ⇤ FServerHello This function additionally accepts a ClientHello message, an optional ServerHello, and an optional server configuration. The ClientHello message is typically the one received in a standard handshake flow, and the other parameters can be thought of as templates for the intended ServerHello message. The function generates a ServerHello message by merging values from the two hello messages and the given configuration; it follows the TLS specification to compute parameters left unspecified by the user. For example, if the user sets the fsh.rand and fsh.version fields, these values will be used for the server randomness and the protocol version, regardless of the ClientHello; conversely, unspecified fields such as the ciphersuite will be chosen from those offered by the client based on a standard negotiation logic.

Each module also offers a prepare() function that produces valid messages without sending them to the network. This enables the user to tamper with the plaintext (or, in the case of encrypted messages, the ciphertext) of the message before sending it via Tcp.write() or by calling the corresponding send() function. Example As a complete example, we show how the full standard protocol scenario of Figure 2 can be encoded as a FLEXTLS script. For simplicity, we only show the client side, and ignore client authentication. The code illustrates how the API can used to succinctly encode TLS protocol scenarios directly from message sequence charts. We refer to the next section and appendix for more detailed examples, and encourage the reader to download and use the tool to understand the full API.

Applications

We have explored three different use cases for FLEXTLS: implementing exploits for protocol and implementation bugs discovered by the authors and third parties (Section 3.1); automated fuzzing of various implementations of the TLS state machine for [START_REF] Beurdouche | A messy state of the union: Taming the composite state machines of TLS[END_REF] (Section 3.2); and rapid prototyping of the current TLS 1.3 draft (Section 3.3). The source code for all these applications is included in the FLEXTLS distribution.

Implementing TLS attacks

We originally intended FLEXTLS as a tool that would allow us to create a proof of concept of the Triple Handshake attack [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF]. It has proved remarkably efficient at this task, and we have since implemented a further seven attacks, including four that have been discovered using the FLEXTLS library itself.

SKIP attack

Several implementations of TLS, including all JSSE versions prior to the January 2015 Java update and CyaSSL up to version 3.2.0, allow key negotiation messages (ServerKeyExchange and ClientKeyExchange) to be skipped altogether, thus enabling a server impersonation attack [START_REF] Beurdouche | A messy state of the union: Taming the composite state machines of TLS[END_REF]. The attacker only needs the certificate of the server to impersonate to mount the attack; since no manin-the-middle tampering is required, the attack is very easy to implement in a few FLEXTLS statements (see Appendix A for a full listing): After the certificate chain of the server to impersonate is sent (line 2), a ServerFinished message is computed based on an empty session key (lines 3-5). Since record encryption is never enabled by the server's CCS message, the attacker is free to send plaintext application data after the ServerFinished message (line 6).

Version rollback by ClientHello fragmentation

OpenSSL (< 1.0.1i) message parsing functions suffer from a bug (CVE-2014-3511) that causes affected servers to negotiate TLS version 1.0, regardless of the highest version offered by the client, when they receive a maliciously fragmented ClientHello, thus enabling a version rollback attack. The tampering of the attacker goes undetected as fragmentation is not authenticated by the TLS handshake. FLEXTLS provides functions that allow record-layer messages to be fragmented in various ways, not just the default minimal fragmentation employed by mainstream TLS libraries. For example, to implement the rollback attack, we first read a ClientHello message regardless of its original fragmentation (line 9); then we forward its first 5 bytes in one fragment (line 10), followed by the rest (line 11).

Tampering with Alerts via fragmentation

The content of the TLS alert sub-protocol is not authenticated during the first handshake (but is afterwards). Alerts are two bytes long and can be fragmented: a single alert byte will be buffered until a second byte is received. If an attacker can inject a plaintext one-byte alert during the first handshake, it will become the prefix of an authentic encrypted alert after the handshake is complete [START_REF] Bhargavan | Implementing TLS with verified cryptographic security[END_REF] FLEXTLS makes it easy to handle independently the two connection states required to implement the man-inthe-middle role of the attacker: sst for the server-side, and cst for the client side. Injecting a single alert byte is easily achieved since all send() functions support sending a manually-crafted byte sequence.

Triple Handshake

Triple Handshake is a class of of man-in-the-middle attacks that relies on synchronizing the master secrets in different TLS connections [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF]. All attack variants rely on a first pair of TLS handshakes where a man-in-the-middle completes the two sessions between different peers, but sharing the same master secret and encryption keys on all connections. We have implemented an HTTPS exploit of the triple handshake attack with FLEXTLS. The full listing of the exploit is included in the FLEXTLS distribution, but significant excerpts also appear below.

The first excerpt shows how the client random value can be synchronized across two connections, while forcing RSA negotiation, by only proposing RSA ciphersuites to the server. The second excerpt shows how the complex task of synchronizing the pre-master secret (PMS) can be implemented with FLEXTLS in just 4 statements. Line 2 gets the PMS from the client: the receiveRSA() function transparently decrypts the PMS using the attacker's private key, then installs it into the next security context. Lines 3-4 transfer the PMS from one security context to the other. Lastly, line 5 sends the synchronized PMS to the server: the sendRSA() function encrypts the PMS with the server public key previously installed in the next security context by the Certificate.receive() function (not shown here). FlexClientKeyExchange.sendRSA(cst,cnsc,cch)

Early CCS injection attack

The early CCS injection vulnerability (CVE-2014-0224) is a state machine bug in OpenSSL (< 1.0.1-h). If a CCS message is injected by a MITM attacker to both client and server immediately after the ServerHello message, both parties will compute a weak master secret consisting of forty-eight null bytes. This weak secret, combined with the public client and server random values, is used to compute the encryption keys on both sides, which are therefore known to the attacker. Later on, the master secret is overwritten with a strong one, but the keys are not, and the attack can be mounted according to the diagram of Figure 3.

Figure 3 CCS Injection Attack

CCS CCS (SNMC=2)

ServerFinished (SNSM=0) ServerFinished (SNMC=0)

Data (SNCM=n) Data (SNMS=n+1) Data (SNSM=n) Data (SNMC=n)
The independent connection states of the client and server roles of the MITM attacker can be synchronized when needed, for instance to install the same weak encryption keys, as shown in lines of the fragment below: Independent connection states make sequence number handling oblivious to the user: we observe that sequence numbers get out of sync on the two sides of the connection (see diagram below), but this is transparently handled by each FLEXTLS connection state.

Export RSA downgrade (aka FREAK)

FREAK [START_REF] Beurdouche | A messy state of the union: Taming the composite state machines of TLS[END_REF] is one of the attacks discovered by the state machine fuzzing feature of FLEXTLS (see Section 3.2 below for details). The attack relies on buggy TLS clients that incorrectly accept an ephemeral RSA ServerKey-Exchange message during a regular RSA handshake. This enables a man-in-the-middle attacker to downgrade the key strength of the RSA key exchange to 512 bits, assuming that the target server is willing to sign an export grade ServerKeyExchange message for the attacker.

The implementation of the attack is fairly straightforward in FLEXTLS: it relies on the attacker negotiating normal RSA with the vulnerable client (lines 11-14), and export RSA with the target server (lines 4-6). Then, the attacker needs to inject the ephemeral ServerKey-Exchange message (line 22-24) to trigger the downgrade.

SmackTLS : Automated Testing

While testing connections to multiple implementations using FLEXTLS, we encountered some functional abnormalities in their state machines. For example, some libraries were not compliant with the TLS specifications and sent mere warning alerts instead of fatal alerts. These signs are characteristic of the existence of severe vulnerabilities, as seen with the JSSE stack [START_REF] Beurdouche | A messy state of the union: Taming the composite state machines of TLS[END_REF].

In order to improve the overall quality of multiple TLS implementations, we expanded FLEXTLS to include some basic fuzzing and testing capabilities. FLEXTLS has the ability to interpret compliant and deviant TLS handshake scenarios, which we call traces. Deviant traces should end with an RFC-compliant alert message, or with a simple TCP closure. We have found that TCP closures, while not RFC-compliant, are common behavior among TLS libraries since they theoretically provide a safe way of tearing down connections so that an attacker does not gain any information about the TLS library's internal state. Results obtained with SMACKTLS, the tool built on top of FLEXTLS to test implementations, show that the correct termination behavior was often incorrectly enforced in a large number of libraries. SMACKTLS endorses multiple functionalities, such as state machine fuzzing and closure testing, while being able to perform either specific tests or patterns of variations in length, shape or content of data to be sent to the scrutinized library. SMACKTLS and FLEXTLS can also serve together as specification compliance testing utilities.

SMACKTLS is very useful for testing the resilience of implementations to a large class of attacks. It is also easy to set up as a Continuous Integration testing tool, to gradually check that a TLS stack does not re-introduce some previously addressed flaws by mistake. We introduce smacktest.com which allows anyone to test their web browser against continuously evolving SMACKTLS traces. smacktest.com reflects the results that can be obtained using FLEXTLS without the necessity of having to build or install it locally. The interface parses FLEXTLS output as it runs traces against the user's browser or client and gives feedback on its security. When a deviant or uncompliant handshake goes through, the user is shown a warning and can explore the trace generated by FLEXTLS when the SMACKTLS scenario is executed. We aim for smacktest.com to be a continuously expansible framework and a service to allow for further client-side testing.

TLS 1.3: Rapid prototyping of new protocol versions

We show a FLEXTLS scenario that implements the draft 1 RTT handshake for the re-designed TLS 1.3 protocol.

Evaluation and Discussion

The primary design goal for FLEXTLS was to be able to succinctly program various TLS protocol scenarios.

The FLEXTLS library comes with more than a dozen exemplary scripts that cover standard TLS 1.2 connections, attack scripts, SMACKTLS tests, as well as prototype TLS 1.3 scenarios. Table 2 evaluates the effectiveness of FLEXTLS when programming 9 of these scenarios. Each row in the table shows the number of TLS messages in a protocol scenario and the amount of lines required to implement it with FLEXTLS. We observe that it takes roughly two statements for every protocol message, even for complex man-in-the-middle attacks or in scenarios that use non-standard cryptographic computations.

Another way to evaluate the effectiveness of FLEXTLS is to look at its real-world impact. The use of FLEXTLS in the SMACKTLS test framework resulted in the discovery of two important attacks on TLS implementations : SKIP and FREAK [START_REF] Beurdouche | A messy state of the union: Taming the composite state machines of TLS[END_REF]. The first proof-of-concept attack demos for these attacks, as well as for the more recent Logjam attack [START_REF] Adrian | Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice[END_REF], were also programmed using FLEXTLS. These demos were used extensively as part of responsible disclosure; they served to convince client and server software vendors of the practicality of the attacks as well as to motivate the suggested fixes. Finally, our FLEXTLS implementations of various TLS 1.3 proposals form the basis for our discussions with and contributions to the TLS working group. By allowing rapid prototyping of the new protocol, FLEXTLS helps to iron out oddities in message formats and cryptographic constructions.

In all these cases, one may arguably have used a different TLS implementation, but in our experience, the ease of use of FLEXTLS has been instrumental in our success. For instance, we discovered the Triple Handshake attack in October 2013, before we had FLEXTLS, and it took several months to develop exploits, explain the attack, and ultimately deploy workarounds for browsers and a long-term countermeasure for the protocol. Now that we have FLEXTLS, the programming effort from our side when disclosing attacks like FREAK and Logjam has been significantly reduced to a matter of weeks or sometimes days. Vendors can download and try the attack at their own site, against their own, possibly proprietary, TLS implementations. Indeed, we are even using FLEXTLS to power smacktest.com, a continuously evolving TLS test server with a simple web interface for running attacks and viewing feedback.

As ongoing work, we are experimenting with the use of FLEXTLS to perform incremental verification of new protocol features before they are integrated into MITLS. For example, we can prove the security of a specific FLEXTLS scenario in isolation, before worrying about how it composes with all the other protocol mechanisms in MITLS. As part of this verification work, we are porting both MITLS and FLEXTLS to F* 2 , a functional programming language that has an expressive dependent type system and supports semi-automated proofs of security and functional correctness. F* programs can be compiled to F#, OCaml, and JavaScript. So, the next version of FLEXTLS will be accessible from all these languages.

FLEXTLS is a TLS-specific protocol testing framework, but similar tools can and should be developed for other protocols like SSH and IPsec. Based on our experience, such tools can be an invaluable platform for communications between security researchers, protocol designers, standards authors, and software developers.

Figure 1

 1 Figure 1 Modular architecture of FlexTLS.

4 nsc

 4 .si (abytes [| (⇤empty⇤) |]) Server st.hs_log in 5 let st, _ = FlexFinished.send(st,verify_data=vd) in 6 FlexAppData.send(st,"... Attacker payload ...")

1

  let alertAttack (server:string, port:int) : state ⇤ state = 2 (⇤ Start being a Man In The Middle ⇤) 3 let sst,_,cst,Forward client hello ⇤) 9 let sst,cst,_ = FlexHandshake.forward(sst,cst) in 10 11 (⇤ Inject a one byte alert to the server ⇤) 12 let cst = FlexAlert.send(cst,Bytes.abytes [| 1uy |]) in 13 14 (⇤ Passthrough mode ⇤) 15 let _ = FlexConnection.passthrough(cst.ns,sst.ns) in 16 (sst, cst)

  1 (⇤ Synchronize client hello randoms, but fixate an RSA key exchange ⇤) 2 let sst,snsc,sch = FlexClientHello.receive(sst) in 3 let cch = { sch with suites = [rsa_kex_cs] } in 4 let cst,cnsc,cch = FlexClientHello.send(cst,cch) in

1 (

 1 ⇤ Synchronize the PMS: decrypt from client; 2 re encrypt to server ⇤) 3 let sst,snsc,scke = 4 FlexClientKeyExchange.receiveRSA(sst,snsc,sch) in 5 let ckeys = {cnsc.keys with kex = snsc.keys.kex} in 6 let cnsc = {cnsc with keys = ckeys} in 7 let cst,cnsc,ccke = 8

1 (

 1 ⇤ Inject CCS to both ⇤) 2 let sst,_ = FlexCCS.send(sst) in 3 let cst,_ = FlexCCS.send(cst) in 4 5 (⇤ Compute and install the weak keys ⇤) 6 let weakKeys = { FlexConstants.nullKeys with 7 ms = (Bytes.createBytes 48 0)} in 8 let wnsc = { nsc with keys = weakKeys } in 9 10 let nscS = FlexSecrets.fillSecrets(sst,Server,wnsc) in 11 let sst = FlexState.installWriteKeys sst wnscS in 12 let wnscC = FlexSecrets.fillSecrets(cst,Client,wnsc) in 13 let cst = FlexState.installWriteKeys cst wnscC in

  Start handshake ⇤) 7 let st,nsc,fch = FlexClientHello.send(st,fch) in 8 let st,nsc,fsh = FlexServerHello.receive(st,fch,nsc) in 9 let st,nsc,fcert = FlexCertificate.receive(st,Client,nsc) in 10 let st,nsc,fske = FlexServerKeyExchange.receiveDHE(st,nsc) 11 let st,fshd = FlexServerHelloDone.receive(st) in 12 let st,nsc,fcke = FlexClientKeyExchange.sendDHE(st,nsc) in 13 let st,_ = FlexCCS.send(st) in 14 15 (⇤ Start encrypting ⇤) 16 let st = FlexState.installWriteKeys st nsc in 17 let st,ffC = FlexFinished.send(st,nsc,Client) in 18 let st,_,_ = FlexCCS.receive(st) in 19 20 (⇤ Start decrypting ⇤) 21 let st = FlexState.installReadKeys st nsc in 22 let st,ffS= FlexFinished.receive(st,nsc,Server) in 23 24 (⇤ Send and receive application data here ⇤) 25 let st = FlexAppData.send(st,utf8 "GET / \r\n") in 26 ...

	1 let clientDHE (server:string, port:int) : state =
	2 (⇤ Offer only one DHE ciphersuite ⇤) 3 let fch = {FlexConstants.nullFClientHello with 4 ciphersuites = Some [DHE_RSA_AES128_CBC_SHA]} in
	5
	6 (⇤

  . Hence, for example, the attacker can turn a fatal alert into an ignored warning, breaking Alert authentication.

	Client	Attacker	Server
	C	M	S
	ClientHello
		Alert([01])	Alert Buffer:
			[01]
	TLS Handshake	TLS Handshake
	Data	Data
	Alert([01;00])		Alert Buffer:
			[01;01;00]

Table 1 :

 1 Test results for TLS server implementations Figure 4 Message sequence chart of TLS 1.3 Start the handshake flow ⇤) let st,nsc,ch= FlexClientHello.send(st,ch,cfg) in let st,nsc,cks= FlexClientKeyShare.send(st,nsc) in let st,nsc,sh= FlexServerHello.receive(st,ch,nsc) in let st,nsc,sks= FlexServerKeyShare.receive(st,nsc) in

	1

Contribution: Rapid prototyping helped finding a parsing issue in the new ClientKeyShare message, and the message format has been fixed in the most current draft. While implementing the FlexTLS.ClientKeyShare module, it became evident that ClientHello and

Table 2 :

 2 FLEXTLS Scenarios: evaluating succinctness

let st, nsc, _ = FlexServerHello.send(st, fch, nsc, fsh) in

let st, nsc, _ = FlexCertificate.send(st, Server, chain, nsc) in

let vd = FlexSecrets.makeVerifyData

Most recent draft available at https://github.com/tlswg/ tls13-spec.

A Full listing of SKIP attack let skip (listening_address:string, ?port:int) : unit = let chain = new System.Security.Cryptography.

X509Certificates.X509Certificate2("cert.cer"). RawData in let port = defaultArg port FlexConstants.defaultTCPPort in


SLANG TERMINOLOGY -OLD PROBLEMS AND NEW SOLUTIONS

Gueorgui Armianov

"Slang is one of those things that everybody can recognize and nobody can define."

.

And yet, the linguistic features that make terms out of ordinary words are rather clear and we can put forward the following characteristics:

1. the single meaning (the monosemy) of the term; 2. its semantic precision; 3. its stylistic neutrality.

It is surprising that as soon as one starts discussing slang, argot or jargon the linguistic and cultural polysemy of these terms immediately brings a very complex and diverse picture to mind. This complexity and this diversity exist in all the countries of Europe and in the United States and they are quite difficult to overcome because of numerous extralinguistic factors. Very often specialists face outdated concepts and bizarre ideas. Scientific studies are regularly opposed to journalistic and non-professional articles, where the main goal is not scientific truth and a precise analysis of the facts but rather the emotional effect on the readers.

Because of this sociocultural opposition and the heterogeneity of the sociolectal terminological apparatus I think that it is important to bring some order to this chaos. In the current context, I will attempt to paint a picture in which the European social dialects (or at least some of them) will be defined and analysed according to their pure linguistic and social characteristics.

The final goal is to elaborate a clear structure, and a common terminological scale for European sociolects where each slang, jargon or argot can find its place.

FRANCE

France is probably the European country where a particular interest in social dialects first appeared. One can find some isolated quotations about jargon (and its variants gargon, gergon and gergo) as early as the 12 th century [START_REF] Robert | Le Petit Robert[END_REF](Robert : 1221) ) and a number of strange encrypted words, dating back to the XIV century, suggest that it is likely that this type of sociolect existed well before that time. The available documents contain some interesting glossaries and show that in the 15 th century the term argot as a 'social dialect of a closed secret group' was unknown in France, while the term jargon existed in the 12 th century. The term argot appears, very likely for the first time, in the work of Olivier Chéreau "Jargon de l'argot réformé", where even the title indicates a social group and not its specific language, its social dialect [START_REF] Chéreau | Jargon de l'argot réformé[END_REF].

The existence of such a meaning is also reflected in the "Dictionnaire universel" of 1771 in which we find the following definition: "argot is also (sic!) the name that the beggars give the language or jargon they use" (Dictionnaire 1771: 495). In his "Anthologie de la littérature argotique", Jacques Cellard also shows that in the 17 th century the term argot possessed only one meaninghe writes: "jargon is a language; argot, a society" (Cellard 1985: 17).

As early as the beginning of the 18 th century, argot began to be used in competition with jargon, which in turn took on a narrower sense: "Jargons are not secret but rather 'professional languages'; and it is in this sense that we must understand the term jargon." (Calvet 1999: 9).

Today, this is the use and the most common meaning of the two terms that we observe in France, not only in the scientific community, but also in the wider circles of writers, journalists and educators. In parallel, one can find many other terms, such as bigorne, cadogan, javanais, jobelin, langue verte, largonji, redegue, tortillage, verlan, etc., that indicate some specific kinds of French sociolects.

Some recent works of the Centre d'Argotologie in Paris support the idea that a distinction should be made between corporate sociolects, professional and mixed (corporate-professional) onesan idea that have been circulating in Eastern Europe for more than 50 years now. Some authors even proposed the term jargot "to refer to all uses where jargon and argot are mixed" (François-Geiger 1991: 7). This term, which is apparently not easy to impose itself, combines quite artificially elements typical of cryptic sociolects with elements of corporate and professional sociolects. Nevertheless, it clearly shows the need to establish a more accurate and understandable sociolectal terminological system.

UNITED KINGDOM

Terminological tradition in Britain and in all English-speaking countries is based on a clear distinction between three basic termsslang, jargon and argot. As a rule, each is linked to a specific type of social dialect, and there is almost no confusion between them. Most authors, when discussing corporate sociolects such as those of pupils, students, soldiers, sports players, drivers, etc., give preference to the term slang.

The use of this term dates back to the Middle Ages and its origin has been the subject of many discussions [START_REF] Hotten | The Slang Dictionary[END_REF]Weekley 1859: 287;[START_REF] Partridge | A Dictionary of Slang and Unconventional English[END_REF]Ritter 1906: 45-49;[START_REF] Westendorpf | Das Prinzip der Verwendung des Slang bei Dickens[END_REF]. Some writers consider slang as everything that looks new and is not in dictionaries of British dialects (Thorne 1990: 26). Others include in this term different language varieties, ranging from secret sociolects to professional terminology. For instance, in the Pocket Oxford Dictionary slang is defined as "very informal words, phrases, or meanings, not regarded as standard and often used by a specific profession, class, etc." (Pocket 1996).

In their book "Bad Language", Lars-Gunnar Andersson and Peter Trudgill prefer not to define the term, and give no less than thirteen largely explained features that should characterize the linguistic variety called slang, namely:

1. Slang is language used below the neutral stylistic level 2. Slang is typical of informal situations 3. Slang is typical of spoken language 4. Slang is found in words, not in grammar 5. Slang is not a dialect 6. Slang is not swearing 7. Slang is not a register 8. Slang is not cant, argot or jargon 9. Slang is creative 10. Slang is often short-lived 11. Slang is often conscious 12. Slang is group-related 13. Slang is ancient (Andersson-Trudgill 1990: 69-81).

Perhaps, the authors were not convinced in the unconditional validity of certain features because they showed the limitations or the exceptions of this classification. They say, for example, that slang is a phenomenon of the spoken language, but immediately emphasize that there are areas where it is widely used, particularly in modern literature and cinema. Then they emphasise that "Slang is not swearing" although one can easily find hundreds of examples of slang swear words and expressions in spoken or written form. Finally, Andersson and Trudgill declare that "Slang is often conscious", but does that mean that in some cases slang is the result of an unconscious activity?

However, in general the term slang in the English-speaking world covers only a specific area of social dialects wherein the roles of expressive linguistic creativity and informal union of people are predominant characteristics.

The other two terms that are positioned at the same level as slang and are clearly defined, are argot and jargon, which represent respectively:  Argot -A more or less secret vocabulary used by a particular class or group (Webster 1996: 52)  Jargon -The technical or specialized vocabulary of a particular profession or group (Webster 1996: 540) Very often in English and American linguistics, we find the term cant, which can be defined as "the restricted, non-technical words and expressions of any particular group, as an occupational, age, ethnic, hobby, or special-interest group." (Britannica 1998). Still, according to this definition, we can compare English cant with sociolects which often bear the name of professional jargon or even slang.

At the same time, in the specialized literature we can discover definitions of the term cant such as "a secret speech of the underworld" (Partridge 1956: 124) or "the slang of professional criminals" (Green 2000: VII) which establish a similarity with the widely known argot [START_REF] Gotti | The Language of Thieves and Vagabonds[END_REF].

In fact, a comparison of the four terms given above and of their meanings in Great Britain and the United States allows us to create a clear scale of the social dialects in these countriesa scale built on the basis of entirely linguistic criteria, and at the same time taking into account some important social differences.

The change in any fundamental feature of a particular sociolect leads to a modification in its nature and to its transformation into a different form. For example, the widening of the narrow usage of cant turns it into slang; the suppression of the specific usage of professional jargon leads to its transformation into standard vocabulary; the disappearance of crypticism of an argot nullifies its own existence.

It is important to point out that there exist several traditional terms in English and American linguistics which have a very broad meaning and sometimes intersect in their use with slang or jargon, for example: tongue [START_REF] Coltharpe | The tongue of the Tirilones: a linguistic study of a criminal argot[END_REF], talk, speech, all of which describe a type of strange, specific, incomprehensible language of a certain social or regional group.

BULGARIA, RUSSIA AND SERBIA

Studies of social dialects in Bulgaria first appeared at the end of the 19 th century. At that time (and in rare cases even today) one could find traditional Bulgarian names, as: tarikatski ezik 'dodger language' [START_REF] Mladenov | Младенов, Тарикатският език на българските ученици[END_REF][START_REF] Hadžidenev | Тарикатството с оглед на българския тарикатски език[END_REF], tarikatski govor 'dodgers dialect' [START_REF] Stojkov | Стойков, Софийският ученически говор[END_REF], tarikatski jargon 'dodgers slang' [START_REF] Popov | К. Попов, Против тарикатския жаргон[END_REF][START_REF] Stojkov | борба срещу тарикатския жаргон[END_REF][START_REF] Andrejčin | Андрейчин, На борба против тарикатския жаргон[END_REF][START_REF] Boyadžiev | Проблеми на езиковата култура[END_REF][START_REF] Părvev | Първев, Тарикатски думи[END_REF], tarikatski dumi 'dodgers words', etc. These names show the "genetic" links that existed between youth slang and the argot of the outlawed until the late 19 th century, but also the hesitations of Bulgarian linguists when it came to finding the most accurate term.

Gradually, since the sixties of the last century, with the deepening of studies in this area, there appeared the necessity to determine sociolectal terminology and to harmonize it with international standards.

At the same time, in parallel to the term social dialect, often used in language studies, authors began to use the term sociolect, created in the 1970s by the German linguists Grosse and Neubert [START_REF] Grosse | Thesen zur marxistischen Soziolinguistik[END_REF][START_REF] Neubert | К вопросе о предмете и основных понятиях марксистко-ленинской социолингвистики[END_REF]). Traditional designations were replaced by the terms jargon and slang, which were gradually imposed in the scientific literature, without any of them becoming accepted as the sole one. In general, these two terms exist as synonyms, and their use is a matter of personal preference rather than of conceptual differences (Pačev 1988: 1).

It should also be noted that some linguists consider the term slang as the notion of species, related only to corporate sociolects, and the term jargon as a generic term which includes all the others. Other authors consider jargon a subordinate part of slang and refer to the use of "jargon words in slang" (Čizmarov 1982: 160-166). Some even judge the term slang as a scientific one and jargon as a "colloquial term" [START_REF] Vălkov | Вълков, За същността на жаргона[END_REF])!

In his "Small encyclopaedia of sociolinguistics" A. Pačev presents slang as a "secret language (speech)", thus repeating the unacceptable mixture between the two SLANG (expressiveness, wide usage and extent)

ARGOT

(crypticism and low social status)

CANT

(expressiveness and narrow extent)

JARGON

(specificity and limited usage) concepts (Pačev 1993: 14). A hundred pages further, he divides jargon into two groupscorporate jargon and outlaw jargonsand when explaining the nature of the second group, he uses the term slang as a synonym for jargon (Pačev 1993: 117).

Still, in the article on the term slang the author presents it as a type of speech (Pačev 1993: 231) without paying attention to the fact that the Bulgarian term "razgovorna reč" means not only spoken language but also 'familiar speech'. At the end he gives almost identical examples of those included in the article about jargon.

The reasons why authors prefer one or the other term are different, but are rarely of a linguistic or scientific nature. It is only recently that some linguists have begun to formulate a difference between jargon and slang, using the former for professional sociolects, as in English-speaking countries, the Czech Republic, Russia and sometimes France, and reserving the latter for corporate sociolects only [START_REF] Videnov | Виденов, Българска социолингвистика, София: Университетско издателство "Св. Климент Охридски[END_REF].

In Bulgaria, as in the most European countries, the term argot exists with only one meaning -'secret social dialect of craftsmen, criminals or outlaws'. This probably facilitates the understanding of the structure, relationships and links within the system of the Bulgarian social dialects, but poses problems when it comes to a comparison with the French system, for example, since in France professionals and amateurs alike prefer to use the term argot to refer to all types and sub-types of social dialects, which are not related to a profession, and especially when referring to the "traditional" sociolects of criminals and youngsters (Marusaut 1960;[START_REF] Esnault | Dictionnaire historique des argots français[END_REF]Quillet 1965;[START_REF] Calvet | L'Argot[END_REF].

In Russia (and in the Soviet Union until 1991), studies of social dialects date from the early 20 th century [START_REF] Trahtenberg | В. Трахтенберг, Блатная музыка/Жаргон тюрмы[END_REF][START_REF] Handzinskij | Blatnaya poeziya[END_REF][START_REF] Potapov | Потапов, Словарь жаргона преступников[END_REF]. Most of them were dedicated to traditional sociolects of merchants and criminals which, as in Bulgaria, had their own aditional Russian names: ofensky yazyk, ofenskoe argot, fenya, blatnaya reč, etc.

In the 1930s some interesting studies were published on Russian professional sociolects, the criminal argot and the language of the city, which, in addition to their obligatory ideology, make a strong impression on the reader with their systematic analysis (Barannikov 1931; Larin 1977 1 ; Čistyakov 1935; Lihačev 1935; Uspenskij 1936).

Just as in Bulgaria, the titles of these articles demonstrate the same hesitation about the terms to employ. The use of the term fenya persists even today in books on contemporary social dialects, like the criminal slang reflected in the book "Russkaya Fenya" of Vladimir Bykov [START_REF] Bykov | [END_REF]). In the preface, the author uses the term "interjargon" to show that use of this sociolect is not strictly limited to a group of criminals or prisoners, but is well known to different and heterogeneous social groups, such as thieves, hooligans, drug dealers and other people placed in different institutions of compulsory labour (Bykov 1994: 3). Then, he subtitled his book "Slovarj russkogo argot", that is to say, "Dictionary of Russian slang", thus creating a mix of scientific terms and traditional names (Bykov 1994: 13).

However, a few pages further on, when Bykov speaks of grammatical and semantic features of the "russkaya fenya", he uses the terms blatnaya muzyka, jargon and thieves' jargon as synonyms for the terms interjargon and fenya (Bykov 1994: 4-9).

The term interjargon was used similarly by L.I. Skvortsov in his article "Standard language, colloquial speech and jargon and their interactions". There he defines the term somewhat differently: "vocabulary that belongs to several jargons", that grows and, as a result, "enters slang" (sic!) (Skvortsov 1997: 35-36). From this point of view, the term interjargon looks similar to the French term jargot mentioned above, but once again we are faced with a pretty obvious terminological confusion.

Although Russian linguists generally use the term argot for secret sociolects of criminals and jargon for corporate and professional sociolects, a confusion between these terms can be noticed even in some university textbooks and academic papers (Valgina 1971: 35;Šmelev 1977: 172;Dešeriev 1981: 80;Šanskij 1981: 49;[START_REF] Bondaletov | В. Бондалетов, Социальная лингвистика[END_REF]. For example, in the article by Skvortsov quoted above, the author uses jargon and argot as absolute synonyms: "The standard language is regularly enriched by words of a dialect, popular and jargon (argot) origin" (Skvortsov 1997: 29).

A few pages further on, he puts argot and jargon as well as "different argot and jargon elements" at a lower level than the terms slang or colloquial speech: "The evolution of jargon to slang and then to colloquial speech is a complex and heterogeneous process... In colloquial speech and in slang enter not only neutralized words belonging to one jargon or another, but also interjargon words" (Skvortsov 1997: 35-38).

Following Skvortsov, we can build a scale on which argot and/or jargon are placed at a low level, slang at a higher level, and above them stands colloquial speech, considered by the author as an integral part of the standard language, but located at its lowest levels.

A different case can be found in the "Slovarj moskosvskogo argot", literally "Dictionary of Moscow argot" by V. S. Elistratov. The author in fact presents the corporate youth sociolect, which is a linguistic variety located very far from argot. The theoretical part of the dictionary, entitled exactly "Argot and culture", begins with a sentence that establishes an equation between the terms slang, jargon and argot: "The problem of argot (i.e. jargons, slangs, etc.) is one of the most complex problems, not only in linguistics but also in all human sciences" (Elistratov 1994: 594).

From this quotation we can conclude that argot (in the singular!) is considered a generic term which is located at the highest level of the sociolectal scale and contains other smaller and limited varieties, as jargons or slangs (in the plural!)a position that cannot be successfully defended. This contradiction still exists in a recent dictionary of Russian slang published by Elistratov, where even in the subtitle he includes the term jargon in the wider variety of slang: "Dictionary of Russian slang

STANDARD LANGUAGE

COLLOQUIAL SPEECH

SLANG ARGOT and JARGON

(more than 12 000 words and phrases; argot; kinemalogos; jargons)" [START_REF] Elistratov | Словарь московского арго[END_REF].

Moreover, in the review of the dictionary published in the prestigious literary journal "Literaturnaya gazeta", the journalist writes that "there are several approaches to argot (slang)", thus repeating the already exposed confusion (Gazeta 2007).

The same confusion exists in the "Manual of linguistic terms" by Rosenthal and Telenkova. At first, the authors use the term argot to refer to all types of social dialects (those of criminals, of schoolchildren, students, athletes, etc.). Jargon is presented as its exact synonym. Unexpectedly, a few dozen pages further, they explain that jargon "is the same as argot, but with a pejorative meaning" [START_REF] Rosenthal | Справочник лингвистических терминов[END_REF]. It is not clear how they come to that conclusion. Similarly, it is surprising that the term slang, well known and used in Russia since the thirties, appears nowhere in this book.

The use of the term slang in Russia (usually written as сленг or слянг, as in Bulgaria) has been rather sporadic and often limited to the context of English studies [START_REF] Sudzilovskij | Сленг, что это такое?[END_REF][START_REF] Makovskij | Маковский, Английские социальные диалекты[END_REF][START_REF] Švejcer | А. Швейцер, Социальная диференциация авглийского языка в США[END_REF], while terms like dialekt 'dialect', reč 'speech', govor 'dialect' and yazyk 'language' are still very common, especially in popular articles. Even in the most recent publications, some ambiguity and mutual substitution of the terms slang and jargon can be observed (Mokienko 2009), though the term slang appears more and more frequently [START_REF] Ponomarev | Вл. Пономарев, Бизнес-сленг для "новых русских[END_REF][START_REF] Nikitina | Толковой словарь[END_REF]. Thus, on the internet-site "Živoe slovo", Elena Marinova asserts that slang is a nonstandard variant of the national language and, by contrast with jargon, is not limited regarding its speakers. It can be used by "people of different professions, different social status, age, education, etc.", while "Jargon as a variant of the national language always has a limitation in terms of the people who use it" [START_REF] Marinova | Сленг и жаргон -синонимы?[END_REF].

A very similar situation exists currently in Serbia and Croatia, where we can observe the same kind of contradictions, inaccuracies or confusions. In both countries, the terms slang, jargon and argot are frequently mixed with other traditional designations as šatra, šatrovački govor, guegavački govor, frayerski govor, etc., which further complicates the understanding and, therefore, the proper use of scientific linguistic terms. In addition, the terms slang, jargon and argot are used with similar or identical meanings to those of their Bulgarian and Russian counterparts. This is valid to a certain degree in Poland as well, while in the Czech Republic and in Slovakia the use of the three scientific terms is fairly clear and unambiguous.

To illustrate this confusing picture, in the table below I have placed the three key termsslang, jargon and argottogether with other traditional national expressions, used to describe certain specific types of sociolects. The countries concerned are France, the United Kingdom, Russia, Bulgaria, Serbia, Poland, and the Czech Republic.

This table shows that the same terms are often used to define distinct linguistic varieties and it is valid not only when we compare the terminological systems of different European countries, but also within the boundaries of a particular country and its terminological system. In France and Russia, for example, the term argot means both "secret language", "language of criminals" and "corporate sociolect." In Bulgaria, Russia and Serbia, the term jargon means "professional sociolect", "corporate sociolect" and "incomprehensible language." If we include here the extraordinary heterogeneity of traditional names of each country, we will get a picture which is as colourful as a patchwork carpet.

This unruly situation requires an attempt to unify the meanings of sociolinguistic and sociolectal terms, which in turn would lead to clarity in the system of social dialects on the Old Continent. Is this feasible in practice? Is it possible to simply ask Bulgarian, Czech, Russian, Slovak or Serbian linguists to replace the wellestablished term jargon with its meaning of 'corporate sociolect' with the English term slang? The answer could be positive, if we take into consideration the fact that these two terms are already competing.

Well, but is this substitution possible in France, where cultural traditions play a very important role and where there is a fierce national fight against the so called "invasion of English words"? Here, the answer is rather no. Furthermore, it could lead to a new terminological synonymy, this time between the term slang and the recently created term jargot which, in a great measure, occupies a similar linguistic space.

Such danger seems quite likely to arise, because even the French linguistic community is pretty heterogeneous, and is not fully ready to adopt such a change even if it is understood as a necessary step towards the unification of terminology in the field of social dialects.

ARGOT

The article was first published in 1931 and is based on an early oral version of 1926; later it was being republished in 1977.