July 2014 - tor-commits - lists.torproject.org

[obfsproxy/master] Increase closing threshold.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit ea2e71ffe07fbb1e8a307d4b33e9718d6b9b2576 Author: Philipp Winter <phw(a)torproject.org> Date: Tue Mar 4 00:04:36 2014 +0100 Increase closing threshold. Since we no longer process data after authentication has failed, we might as well increase the closing threshold. The larger interval hopefully makes ScrambleSuit bridges less fingerprintable for active adversaries. --- obfsproxy/transports/scramblesuit/state.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/obfsproxy/transports/scramblesuit/state.py b/obfsproxy/transports/scramblesuit/state.py index f015755..8068914 100644 --- a/obfsproxy/transports/scramblesuit/state.py +++ b/obfsproxy/transports/scramblesuit/state.py @@ -116,7 +116,7 @@ class State( object ): # Unauthenticated connections are closed after having received the # following amount of bytes. self.closingThreshold = prng.randint(const.MAX_HANDSHAKE_LENGTH, - const.MAX_HANDSHAKE_LENGTH * 2) + const.MAX_HANDSHAKE_LENGTH * 5) self.writeState()

1 0

[obfsproxy/master] Add scramblesuit unittests for the state module.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit 5333b1b650667409a7dc52cb646b2a822e3a2c80 Author: George Kadianakis <desnacked(a)riseup.net> Date: Mon Apr 14 15:01:01 2014 +0300 Add scramblesuit unittests for the state module. --- obfsproxy/test/transports/test_scramblesuit.py | 47 ++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/obfsproxy/test/transports/test_scramblesuit.py b/obfsproxy/test/transports/test_scramblesuit.py index 541d92e..df7f69b 100644 --- a/obfsproxy/test/transports/test_scramblesuit.py +++ b/obfsproxy/test/transports/test_scramblesuit.py @@ -19,6 +19,8 @@ import obfsproxy.transports.scramblesuit.mycrypto as mycrypto import obfsproxy.transports.scramblesuit.uniformdh as uniformdh import obfsproxy.transports.scramblesuit.scramblesuit as scramblesuit import obfsproxy.transports.scramblesuit.message as message +import obfsproxy.transports.scramblesuit.state as state + # Disable all logging as it would yield plenty of warning and error # messages. @@ -226,6 +228,51 @@ class UtilTest( unittest.TestCase ): # Read file where we (hopefully) don't have permissions. self.failUnless(util.readFromFile("/etc/shadow") == None) +class StateTest( unittest.TestCase ): + + def setUp( self ): + const.STATE_LOCATION = "/tmp/" + self.stateFile = const.STATE_LOCATION + const.SERVER_STATE_FILE + self.state = state.State() + + def tearDown( self ): + try: + os.unlink(self.stateFile) + except OSError: + pass + + def test1_genState( self ): + self.state.genState() + self.failUnless(os.path.exists(self.stateFile)) + + def test2_loadState( self ): + # load() should create the state file if it doesn't exist yet. + self.failIf(os.path.exists(self.stateFile)) + self.failUnless(isinstance(state.load(), state.State)) + self.failUnless(os.path.exists(self.stateFile)) + + def test3_replay( self ): + key = "A" * const.HMAC_SHA256_128_LENGTH + self.state.genState() + self.state.registerKey(key) + self.failUnless(self.state.isReplayed(key)) + self.failIf(self.state.isReplayed("B" * const.HMAC_SHA256_128_LENGTH)) + + def test4_ioerrorFail( self ): + def fake_open(name, mode): + raise IOError() + self.state.genState() + + import __builtin__ + real_open = __builtin__.open + __builtin__.open = fake_open + + # Make state.load() fail + self.assertRaises(SystemExit, state.load) + # Make State.writeState() fail. + self.assertRaises(SystemExit, self.state.genState) + + __builtin__.open = real_open class MockArgs( object ): uniformDHSecret = sharedSecret = ext_cookie_file = dest = None

1 0

[obfsproxy/master] Add TicketTest unittest.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit b3fd09f6fc0326dd73ee2927fd70b6afa592738a Author: George Kadianakis <desnacked(a)riseup.net> Date: Mon Apr 14 15:08:52 2014 +0300 Add TicketTest unittest. --- obfsproxy/test/transports/test_scramblesuit.py | 57 ++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/obfsproxy/test/transports/test_scramblesuit.py b/obfsproxy/test/transports/test_scramblesuit.py index df7f69b..3392b5f 100644 --- a/obfsproxy/test/transports/test_scramblesuit.py +++ b/obfsproxy/test/transports/test_scramblesuit.py @@ -20,6 +20,7 @@ import obfsproxy.transports.scramblesuit.uniformdh as uniformdh import obfsproxy.transports.scramblesuit.scramblesuit as scramblesuit import obfsproxy.transports.scramblesuit.message as message import obfsproxy.transports.scramblesuit.state as state +import obfsproxy.transports.scramblesuit.ticket as ticket # Disable all logging as it would yield plenty of warning and error @@ -167,6 +168,30 @@ class UniformDHTest( unittest.TestCase ): self.failIf(self.udh.receivePublicKey(buf, lambda x: x) == True) + def test4_extractPublicKey( self ): + + # Create UniformDH authentication message. + sharedSecret = "A" * const.SHARED_SECRET_LENGTH + + realEpoch = util.getEpoch + + # Try three valid and one invalid epoch value. + for epoch in util.expandedEpoch() + ["000000"]: + udh = uniformdh.new(sharedSecret, True) + + util.getEpoch = lambda: epoch + authMsg = udh.createHandshake() + util.getEpoch = realEpoch + + buf = obfs_buf.Buffer() + buf.write(authMsg) + + if epoch == "000000": + self.assertFalse(udh.extractPublicKey(buf)) + else: + self.assertTrue(udh.extractPublicKey(buf)) + + class UtilTest( unittest.TestCase ): def test1_isValidHMAC( self ): @@ -360,6 +385,38 @@ class MessageTest( unittest.TestCase ): self.assertRaises(base.PluggableTransportError, message.ProtocolMessage, "1", paddingLen=const.MPU) +class TicketTest( unittest.TestCase ): + + def test1_authentication( self ): + srvState = state.State() + srvState.genState() + + ss = scramblesuit.ScrambleSuitTransport() + ss.srvState = srvState + + realEpoch = util.getEpoch + + # Try three valid and one invalid epoch value. + for epoch in util.expandedEpoch() + ["000000"]: + + util.getEpoch = lambda: epoch + + # Prepare ticket message. + blurb = ticket.issueTicketAndKey(srvState) + rawTicket = blurb[const.MASTER_KEY_LENGTH:] + masterKey = blurb[:const.MASTER_KEY_LENGTH] + ss.deriveSecrets(masterKey) + ticketMsg = ticket.createTicketMessage(rawTicket, ss.recvHMAC) + + util.getEpoch = realEpoch + + buf = obfs_buf.Buffer() + buf.write(ticketMsg) + + if epoch == "000000": + self.assertFalse(ss.receiveTicket(buf)) + else: + self.assertTrue(ss.receiveTicket(buf)) if __name__ == '__main__': unittest.main()

1 0

[obfsproxy/master] Make the server simply echo the client's epoch.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit 37fb7903588171ce7b73b7eb973590aff2a76736 Author: Philipp Winter <phw(a)torproject.org> Date: Tue Mar 4 20:34:16 2014 +0100 Make the server simply echo the client's epoch. That's only relevant for UniformDH. --- obfsproxy/transports/scramblesuit/uniformdh.py | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/obfsproxy/transports/scramblesuit/uniformdh.py b/obfsproxy/transports/scramblesuit/uniformdh.py index b070b10..1b59575 100644 --- a/obfsproxy/transports/scramblesuit/uniformdh.py +++ b/obfsproxy/transports/scramblesuit/uniformdh.py @@ -46,6 +46,9 @@ class UniformDH( object ): # Uniform Diffie-Hellman object (implemented in obfs3_dh.py). self.udh = None + # Used by the server so it can simply echo the client's epoch. + self.echoEpoch = None + def getRemotePublicKey( self ): """ Return the cached remote UniformDH public key. @@ -117,13 +120,15 @@ class UniformDH( object ): if not index: return False + self.echoEpoch = util.getEpoch() + # Now that we know where the authenticating HMAC is: verify it. hmacStart = index + const.MARK_LENGTH existingHMAC = handshake[hmacStart: (hmacStart + const.HMAC_SHA256_128_LENGTH)] myHMAC = mycrypto.HMAC_SHA256_128(self.sharedSecret, handshake[0 : hmacStart] + - util.getEpoch()) + self.echoEpoch) if not util.isValidHMAC(myHMAC, existingHMAC, self.sharedSecret): log.warning("The HMAC is invalid: `%s' vs. `%s'." % @@ -174,10 +179,15 @@ class UniformDH( object ): # Add a mark which enables efficient location of the HMAC. mark = mycrypto.HMAC_SHA256_128(self.sharedSecret, publicKey) + if self.echoEpoch is None: + epoch = util.getEpoch() + else: + epoch = self.echoEpoch + log.debug("Echoing epoch rather than recreating it.") + # Authenticate the handshake including the current approximate epoch. mac = mycrypto.HMAC_SHA256_128(self.sharedSecret, - publicKey + padding + mark + - util.getEpoch()) + publicKey + padding + mark + epoch) return publicKey + padding + mark + mac

1 0

[obfsproxy/master] Let the server echo the epoch.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit 33e7c8995d2b7b1ea317bd07d7833a8af6f1f6fe Author: Philipp Winter <phw(a)torproject.org> Date: Tue Mar 4 20:04:45 2014 +0100 Let the server echo the epoch. There's no need for the server to determine its own epoch. --- doc/scramblesuit/scramblesuit-spec.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt index 45a35f5..e9de667 100644 --- a/doc/scramblesuit/scramblesuit-spec.txt +++ b/doc/scramblesuit/scramblesuit-spec.txt @@ -71,7 +71,8 @@ by 3600. It represents the amount of hours which have passed since the epoch. It is used by the client and the server to prove liveness. For example, the Unix timestamp 1378768086 would map to E = 1378768086 / 3600 = - "382991". + "382991". While the client MUST determine E, the server can simply echo + the client's E in its response. The server's handshake message is created analogous to the client. @@ -124,7 +125,8 @@ by 3600. It represents the amount of hours which have passed since the epoch. It is used by the client and the server to prove liveness. For example, the Unix timestamp 1378768086 would map to E = 1378768086 / 3600 = - "382991". + "382991". While the client MUST determine E, the server can simply echo + the client's E in its response. Client Server Legend: | T | P | M | MAC(T | P | E) | T: session ticket

1 0

[obfsproxy/master] Add missing reference.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit d50a2cc615bdfef1122ccac12398397948b5312e Author: Philipp Winter <phw(a)torproject.org> Date: Sat Mar 8 17:38:12 2014 +0100 Add missing reference. --- doc/scramblesuit/scramblesuit-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt index e9de667..208b264 100644 --- a/doc/scramblesuit/scramblesuit-spec.txt +++ b/doc/scramblesuit/scramblesuit-spec.txt @@ -104,7 +104,7 @@ A client can authenticate itself towards a ScrambleSuit server by redeeming a 112-byte session ticket T. Such a ticket contains the master key k_t and is encrypted and authenticated using keys only known to the server. The - structure of a session ticket is discussed in Section XXX. If a valid + structure of a session ticket is discussed in Section 5.1. If a valid session ticket is available, a client SHOULD redeem it rather than conduct a UniformDH handshake.

1 0

[obfsproxy/master] When authenticating, also test epoch boundaries.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit fd4a91192ccab2cfda2c4b7887730a84152d5fa7 Author: Philipp Winter <phw(a)torproject.org> Date: Sat Mar 8 16:42:31 2014 +0100 When authenticating, also test epoch boundaries. On occasion, a client's or a server's epoch might already have increased whereas the epoch of the other party didn't. This is a benign event and there is no reason to fail authentication because of this. As a result, as a server, we now also test boundary values, i.e., epoch - 1, epoch, epoch + 1. --- obfsproxy/transports/scramblesuit/scramblesuit.py | 22 +++++++++++++-------- obfsproxy/transports/scramblesuit/uniformdh.py | 22 +++++++++++++-------- obfsproxy/transports/scramblesuit/util.py | 10 ++++++++++ 3 files changed, 38 insertions(+), 16 deletions(-) diff --git a/obfsproxy/transports/scramblesuit/scramblesuit.py b/obfsproxy/transports/scramblesuit/scramblesuit.py index 7e96044..87a7370 100644 --- a/obfsproxy/transports/scramblesuit/scramblesuit.py +++ b/obfsproxy/transports/scramblesuit/scramblesuit.py @@ -388,14 +388,20 @@ class ScrambleSuitTransport( base.BaseTransport ): existingHMAC = potentialTicket[index + const.MARK_LENGTH: index + const.MARK_LENGTH + const.HMAC_SHA256_128_LENGTH] - myHMAC = mycrypto.HMAC_SHA256_128(self.recvHMAC, - potentialTicket[0: - index + const.MARK_LENGTH] + - util.getEpoch()) - - if not util.isValidHMAC(myHMAC, existingHMAC, self.recvHMAC): - log.warning("The HMAC is invalid: `%s' vs. `%s'." % - (myHMAC.encode('hex'), existingHMAC.encode('hex'))) + authenticated = False + for epoch in util.expandedEpoch(): + myHMAC = mycrypto.HMAC_SHA256_128(self.recvHMAC, + potentialTicket[0:index + \ + const.MARK_LENGTH] + epoch) + + if util.isValidHMAC(myHMAC, existingHMAC, self.recvHMAC): + authenticated = True + break + + log.debug("HMAC invalid. Trying next epoch value.") + + if not authenticated: + log.warning("Could not verify the authentication message's HMAC.") return False # Do nothing if the ticket is replayed. Immediately closing the diff --git a/obfsproxy/transports/scramblesuit/uniformdh.py b/obfsproxy/transports/scramblesuit/uniformdh.py index 1b59575..dd16070 100644 --- a/obfsproxy/transports/scramblesuit/uniformdh.py +++ b/obfsproxy/transports/scramblesuit/uniformdh.py @@ -120,19 +120,25 @@ class UniformDH( object ): if not index: return False - self.echoEpoch = util.getEpoch() - # Now that we know where the authenticating HMAC is: verify it. hmacStart = index + const.MARK_LENGTH existingHMAC = handshake[hmacStart: (hmacStart + const.HMAC_SHA256_128_LENGTH)] - myHMAC = mycrypto.HMAC_SHA256_128(self.sharedSecret, - handshake[0 : hmacStart] + - self.echoEpoch) - if not util.isValidHMAC(myHMAC, existingHMAC, self.sharedSecret): - log.warning("The HMAC is invalid: `%s' vs. `%s'." % - (myHMAC.encode('hex'), existingHMAC.encode('hex'))) + authenticated = False + for epoch in util.expandedEpoch(): + myHMAC = mycrypto.HMAC_SHA256_128(self.sharedSecret, + handshake[0 : hmacStart] + epoch) + + if util.isValidHMAC(myHMAC, existingHMAC, self.sharedSecret): + self.echoEpoch = epoch + authenticated = True + break + + log.debug("HMAC invalid. Trying next epoch value.") + + if not authenticated: + log.warning("Could not verify the authentication message's HMAC.") return False # Do nothing if the ticket is replayed. Immediately closing the diff --git a/obfsproxy/transports/scramblesuit/util.py b/obfsproxy/transports/scramblesuit/util.py index bb0557e..ee25f95 100644 --- a/obfsproxy/transports/scramblesuit/util.py +++ b/obfsproxy/transports/scramblesuit/util.py @@ -106,6 +106,16 @@ def getEpoch( ): return str(int(time.time()) / const.EPOCH_GRANULARITY) +def expandedEpoch( ): + """ + Return [epoch, epoch-1, epoch+1]. + """ + + epoch = int(getEpoch()) + + return [str(epoch), str(epoch - 1), str(epoch + 1)] + + def writeToFile( data, fileName ): """ Writes the given `data' to the file specified by `fileName'.

1 0

[obfsproxy/master] Fix ticket handshake spec.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit 39aa6ffabe29ae305fbb1c36e78a9abb154e0894 Author: Philipp Winter <phw(a)torproject.org> Date: Sat Mar 8 17:40:35 2014 +0100 Fix ticket handshake spec. The first message makes use of the HMAC key which is derived from the master key. It does not use the master key itself. --- doc/scramblesuit/scramblesuit-spec.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt index 208b264..f928845 100644 --- a/doc/scramblesuit/scramblesuit-spec.txt +++ b/doc/scramblesuit/scramblesuit-spec.txt @@ -114,12 +114,14 @@ uniformly chosen from {0..1388} bytes. After the padding, a 16-byte mark M is appended which is defined as: - M = HMAC-SHA256-128(k_t, T) + M = HMAC-SHA256-128(k_sh, T) The mark is used to easily locate the MAC which is the last part of the - handshake. The MAC is defined as: + handshake. k_sh is the 256-bit HMAC key which is used by the client to + authenticate outgoing data. It is derived from k_t (which is embedded in + the ticket) as described in Section 2.3. The MAC is defined as: - MAC = HMAC-SHA256-128(k_t, T | P | E) + MAC = HMAC-SHA256-128(k_sh, T | P | E) The variable E is a string representation of the current Unix epoch divided by 3600. It represents the amount of hours which have passed since the

1 0

[obfsproxy/master] Elaborate on protocol polymorphism.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit 685c0f689d75d83ce4defbc8c361d3ac2612f532 Author: Philipp Winter <phw(a)torproject.org> Date: Sun Mar 9 00:14:59 2014 +0100 Elaborate on protocol polymorphism. While the general idea is explained, there are no exact details. Implementations may use different (CS)PRNGs to derive probability distributions. Such "flow diversity" might even be beneficial. Conflicts: doc/scramblesuit/scramblesuit-spec.txt --- doc/scramblesuit/scramblesuit-spec.txt | 57 +++++++++++++++++++++++++++++--- 1 file changed, 53 insertions(+), 4 deletions(-) diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt index f928845..ee925fa 100644 --- a/doc/scramblesuit/scramblesuit-spec.txt +++ b/doc/scramblesuit/scramblesuit-spec.txt @@ -234,10 +234,59 @@ probability distributions from which random samples are drawn. These random samples dictate specific inter-arrival times and packet lengths. Both probability distributions are generated based on a random 256-bit PRNG - seed which is different for every ScrambleSuit server. Servers communicate - their seed to clients in a protocol message whose FLAG_PRNG_SEED bit is set - to "1". The client then extracts the PRNG seed and derives the same - probability distributions as the server. + seed which is unique for every ScrambleSuit server. Servers communicate + their seed to clients in a dedicated protocol message whose FLAG_PRNG_SEED + bit is set. The client then extracts the PRNG seed and derives its own + probability distributions. + +4.1 Deriving Probability Distributions + + Probability distributions SHOULD be derived from the 256-bit seed using a + cryptographically secure PRNG. After the CSPRNG was seeded, the amount of + bins for the respective probability distribution must be determined. + Depending on the CSPRNG's output, the amount SHOULD be uniformly chosen + from {1..100}. The exact way how the CSPRNG's output is used is up to the + implementation. + + After the amount of bins has been determined, every bin is assigned a value + together with a corresponding probability which is in the interval ]0, 1]. + The probability of all bins sums up to 1. Again, the exact way how the + CSPRNG's output is used is up to the implementation. + + For the packet length distribution, all values SHOULD be in {21..1448}. + + For the inter-arrival time distribution, all values SHOULD be in the + interval [0, 0.01]. + + Since the distributions are generated randomly, it is possible that they + cause particularly bad throughput. To prevent this, implementations MAY + trade off obfuscation for additional throughput by carefully tuning the + above parameters. + +4.2 Packet Length Obfuscation + + In general, ScrambleSuit transmits MTU-sized segments as long as there is + enough data in the send buffer. Packet length obfuscation only kicks in + once the send buffer is almost processed and a segment smaller than the MTU + would have to be sent. + + Instead of simply flushing the send buffer, a random sample from the + discrete packet length probability distribution is drawn. Padding messages + are then appended so that the size of the last segment in the burst equals + the freshly drawn sample. + +4.3 Inter-arrival Time Obfuscation + + To obfuscate inter-arrival times, implementations could maintain a + dedicated send buffer. As long as there is data in the send buffer, random + samples from the inter-arrival time distribution are drawn. The thread + processing the send buffer is then paused for the duration of the freshly + drawn sample until the next MTU-sized chunk is written to the wire. This + process is repeated until the send buffer is empty. + + Note that inter-arrival time obfuscation has a drastic impact on + throughput. As a result, implementations MAY implement packet length + obfuscation but ignore inter-arrival time obfuscation. 5. Session Tickets

1 0

[obfsproxy/master] Add missing markers to HMACs.
by asn＠torproject.org 15 Jul '14

15 Jul '14

commit d68eb5caa5a85bdef2652cdebb6d3a832c184393 Author: Philipp Winter <phw(a)torproject.org> Date: Sun Mar 9 01:41:28 2014 +0100 Add missing markers to HMACs. Thanks to Yawning Angel for catching this. --- doc/scramblesuit/scramblesuit-spec.txt | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt index ee925fa..d910258 100644 --- a/doc/scramblesuit/scramblesuit-spec.txt +++ b/doc/scramblesuit/scramblesuit-spec.txt @@ -65,7 +65,7 @@ The mark is used to easily locate the MAC which is the last element of the client's handshake message. The 16-byte MAC is defined as: - MAC = HMAC-SHA256-128(k_B, X | P_C | E) + MAC = HMAC-SHA256-128(k_B, X | P_C | M_C | E) The variable E is a string representation of the current Unix epoch divided by 3600. It represents the amount of hours which have passed since the @@ -121,7 +121,7 @@ authenticate outgoing data. It is derived from k_t (which is embedded in the ticket) as described in Section 2.3. The MAC is defined as: - MAC = HMAC-SHA256-128(k_sh, T | P | E) + MAC = HMAC-SHA256-128(k_sh, T | P | M | E) The variable E is a string representation of the current Unix epoch divided by 3600. It represents the amount of hours which have passed since the @@ -130,13 +130,13 @@ "382991". While the client MUST determine E, the server can simply echo the client's E in its response. - Client Server Legend: - | T | P | M | MAC(T | P | E) | T: session ticket - | ---------------------------> | P: random padding - | AEnc(k_t+1 | T_t+1) | M: mark to locate the MAC - | <--------------------------- | E: approximate timestamp - | AEnc(Tor traffic) | k_t+1: future master key - | <--------------------------> | T_t+1: future ticket + Client Server Legend: + | T | P | M | MAC(T | P | M | E) | T: session ticket + | -------------------------------> | P: random padding + | AEnc(k_t+1 | T_t+1) | M: mark to locate the MAC + | <------------------------------- | E: approximate timestamp + | AEnc(Tor traffic) | k_t+1: future master key + | <------------------------------> | T_t+1: future ticket The server is initially unable to distinguish between a session ticket handshake and a UniformDH handshake as both handshakes are computationally @@ -144,10 +144,10 @@ opportunistically decrypt the session ticket T after verifying its MAC. If the ticket's MAC (which should not be confused with the handshake message's MAC) is valid and the ticket can be decrypted and is not yet expired, the - server then verifies the MAC which is built over T | P | E. If this MAC is - valid, the handshake succeeded. The server, like the client, then proceeds - to derive session keys from the 256-bit master key as described in Section - 2.3. + server then verifies the MAC which is built over T | P | M | E. If this + MAC is valid, the handshake succeeded. The server, like the client, then + proceeds to derive session keys from the 256-bit master key as described in + Section 2.3. After a ticket handshake succeeded, the server replies by issuing a new session ticket T_t+1 together with the according master key k_t+1. The

1 0