FREE ELECTRONIC LIBRARY - Theses, dissertations, documentation

Pages:     | 1 | 2 || 4 |

«Transcript of Episode #478 Page 1 of 18 Transcript of Episode #478 Poodle Bites Description: After catching up with a few interesting events from the ...»

-- [ Page 3 ] --

There are problems with a simple XOR cipher, though, such as you absolutely have to make sure you never use the same stream twice because then the whole thing falls apart in interesting ways that we have talked about in prior podcasts. By comparison, cipher block chaining uses a block cipher like AES, the Rijndael cipher that we're using now, which is 128-bit block.

The Rijndael cipher, and if anyone isn't familiar with it we did a beautiful podcast on it [SN-033] on AES some years ago when Rijndael had been chosen as the Advanced Encryption Standard (AES) cipher for the industry, and that was an NIST-based competition that looked at all the various candidates and said, okay, we like this for - it meets all of our criteria better than any other cipher, so we're choosing it. That one takes 128 bits, or 16 eight-bit bytes at a time, and converts those, sort of maps them to a different 128 bits, under the influence of a key. So the key uniquely determines the mapping between the 2^128 possible input bit combinations into a uniquely different 2^128 output.

The problem with CBC is that it is a block cipher, which is to say it only operates in these 16-byte blocks; whereas RC4 you could say, eh, my data is 55 bytes long. Give me 55 random bytes, which I will XOR with my 55 bytes of plaintext, and out comes 55 bytes of ciphertext. The problem with block ciphers is they work only in multiples of the encryption block size, which is in this case 16 bytes. So if you have any data you're wanting to transmit or encrypt which is not an even multiple of 16, you have to round it up with a process called "padding." You pad the balance out to an even block size multiple so that you can then run it through this block-at-a-time process.

–  –  –

any cryptographic operation before verifying the MAC" - the MAC is the so-called Message Authentication Code. "If you have to perform any cryptographic operation before verifying the MAC on a message you've received, it will somehow inevitably lead to doom." Which is to say that, when you receive a message, absolutely the only safe thing to do is check to see if it's been tampered with. Don't do anything else. First verify that the message is authentic using the Message Authentication Code, the MAC.

Unfortunately, the guys who designed SSL got it backwards. SSL authenticates, then encrypts when it's sending. Which means that we have to reverse the process when we're decrypting, meaning that when we get the message, we have to, because it was authenticated, then encrypted, we have to decrypt, then authenticate. So that breaks this rule of never doing anything other than check for tampering. We decrypt, then we do the tamper checking in SSL protocol. And that's a critical downfall in the original design, and it's the way the BEAST attack happened that we discussed a few years back.

And this is essentially a variation on BEAST. Once we've been able to downgrade the communication from TLS to SSL v3, due to the fact that we decrypt, then we authenticate, it is possible for someone in the middle, in a man-in-the-middle position, very much the way that it happens with BEAST, to probe the communications, to probe the decryption. The padding at the end of the message is checked separately at decryption because padding is a process of encrypting. You have to pad, then you encrypt; which means you decrypt, and then you check the padding. So, and the padding is always by definition from - it's the last block of the cipher is the pad content.

And the way the CBC cipher works, when you're decrypting something that was encrypted with CBC, the second to the last block of ciphertext, that is, the text to be decrypted, is XORed with the last block of plaintext. So, and it's sort of an unfortunate characteristic of cipher block chaining. But what that means is that, if an attacker can mess with the second to the last block of ciphertext, they can, that is, by flipping bits in the second to the last block of ciphertext, they can induce bit flips in the last block of plaintext.

What that does is it gives an attacker control over the tail end of the message and allows them to essentially probe the plaintext because what happens is, after the decryption occurs, the padding is checked. And if the padding is wrong, it'll generate a padding error before it generates a message authentication failure. And that allows the attacker to essentially probe the plaintext by looking at the errors being returned by the server.

Now, this takes a long time. This, for example, takes 256, on average - wait, is 128 or 256? In what I was reading, the analysis kept saying 256. It seemed to me they ought to be able to get lucky, and it ought to be an average of 128. So maybe it was a maximum of 256 and an average of 128, which is half the number of possibilities of eight bits. So they probe one byte at a time in order to obtain the information about the plaintext, then go to the next byte. So first of all, many of the reports said that it would require several hundred probes. In fact, several hundred probes gets you one byte of information. So it's actually several thousand probes in order to get you a chunk of bytes, like a cookie, for example.

Now, okay. So what are we trying to get here? Let's step back from this for a second.

The bad guy, the attacker in the middle, would love to, for example, get the session cookie. Remember that once the user logs in, provides their credentials when they log in, they maintain a persistent session with the remote server because every time their browser, so long as they're logged in, makes additional queries to the remote server, it provides the cookie, saying - reminding the server for every single query, this is who I am, this is who I am, this is me coming back, and here I am again, and here I am. So Security Now! Transcript of Episode #478 Page 14 of 18 that's the session cookie. And the lengths vary. Typically they're huge, like long mothers.

So it's going to take many sets of multiple hundreds of probes stepping through in order to extract the cookie. Now, where do these probes come from? Well, the probes have to originate from the browser. That is, the man in the middle, this is all opaque to the attacker who has poised himself in the middle. They're seeing gibberish go by. And so because they have an intimate knowledge, because they've forced a downgrade to SSL v3, they know what protocol has been negotiated, but they don't have access to the encryption keys. That was securely negotiated by SSL3.

So they're being forced to futz with the data going from the client to the server, making changes, introducing errors. Which means part of this attack requires malicious code in the browser to initiate these thousands of queries. So one of the reasons the bar is so high on this is that, not only do you have to have an attacker who's positioned themselves in the middle, but the page which is generating these queries has to be running malicious code in the context of the site that you're attacking. Because, remember, we also have the whole same domain protection that prevents script from obtaining information about any other domain. It's only able to receive information to look at the domain information for the domain from which the script, its same origin, from which the script originated.

So somehow the attacker not only has to get themselves in the middle, but they have to inject malicious code into the user's browser. And that causes the browser to be initiating all of these hundreds of queries. And the attacker has to have some sort of a dialogue, establish a dialogue so that it's able to tell the clients, the malware running in the client, okay, got that byte. Now what has to happen is the client needs to pad the query by putting some additional stuff in the header to force the cookie to change its byte alignment because the attack requires - the attack operates on the boundary of successive blocks of decryption. So, first of all, this is very complicated. And it requires active participation by malicious code in the browser.

Okay. So let's assume that somehow all of this happens, that an attacker is able to arrange to make that happen. They have to get themselves in line. They have to be able to modify traffic. They have to be able to inject somehow into a session that they've - it's never clear how they can inject anything into the browser. I mean, this is a secure page.

And all they're able to do with thousands of queries which they've induced the browser to generate, and they're breaking the queries as they zoom by in order to cause the server to generate - in order to send back padding errors that allow the attacker to eventually determine a single byte, then tell the browser, okay, got that one, shift everything down, now I'm going to work on getting the next one. So it's never been made clear how that malicious script gets running in the browser, but that's another requirement for this.

So the bar for pulling this off requires all of that to be in place. So I'm going to, after Leo tells us about our final sponsor of the podcast, explain what the official fix is, why GRC doesn't care, and why this entire thing is completely bogus, and not just because it's hard to do, because it's ridiculous.

Okay. So, first of all, the recommendations in the industry which flew around last week with great gasps and breathless instructions and websites popping up to warn people if somebody still supported SSL 3.0, was either to, well, disable CBC. Except, what, then you're going to fall back to RC4? That doesn't work. So it's disable SSL3 completely. That was the only remediation anyone had. I hope people are a little skeptical now that anyone could actually pull this off. It's not even clear to me how it could actually be done. But in a minute I'll tell you why no one ever will.

Security Now! Transcript of Episode #478 Page 15 of 18 The official fix is very clever. And that is that, remember how I said, during the negotiation of the protocol, the client provides a list of the ciphers that it supports that's called the "cipher suite," the suite of ciphers that it knows about - sends it up to the server. Server looks over them and picks hopefully a good one that they share, and then that's what they use.

Well, there have been other things in the past that have sort of "overloaded," as the term is in programming, overloaded that with additional meaning. And there is a pseudo cipher suite called TLS Fallback SCSV, stands for TLS Fallback Signaling Cipher Suite Value. And it's included in the list of ciphers which the client knows about. But it doesn't represent a cipher. It represents an assertion that it knows about TLS because only if it knows about TLS would it know to include it in the list.

And so this is very clever because, if an attacker tried to perform the downgrade attack by faulting that initial handshake, the client would, believing that it had no choice, drop back to SSL3. But it would still include the TLS Fallback SCSV value. The server that's also aware of TLS would have seen an, oh, would not have received that initial handshake because the man in the middle grabbed it, blocked it, and returned an error.

So what the server sees is an SSL3 request that includes in the cipher suite negotiation the TLS Fallback SCSV value. Which is to say, specifically to detect this. And the server says no. That tells the server that the client is asking for an SSL3 connection while knowing about TLS. A client should ask for a TLS connection if it's including the TLS Fallback among its cipher suite values.

So it's a beautiful prevention for this kind of protocol downgrade. Unfortunately, it's new.

And that means the right solution for this problem is for the endpoints to upgrade to support this. OpenSSL immediately added support. If you update to whatever your platform is, if you're a Linux or a UNIX, and you update your system to the latest OpenSSL, it now knows about this. Now, it's got to be supported at each end. So we need the servers to update, too. I imagine next month Microsoft will have a patch for all of their supported servers and platforms, because you can also receive connections on a non-server, to add TLS Fallback SCSV support. That's the right answer. That completely solves the problem.

Now, GRC is not vulnerable because I don't use cookies. In fact, I don't use any state in my ciphers. I've mentioned this before, but even my eCommerce system operates in a cookie-free fashion. After the user has provided some information, that's encrypted in a blob for which only GRC has the key and provided back to the user with their next page.

And then when they submit that, the blob is returned. So at no point does GRC ever have any state information. No one has to log into GRC. There is no notion of logging into GRC. We do have cookies, but that's only for background R&D, to sort of look at statistics of how cookies are being handled by different browsers. We use it for nothing.

So for anyone who is worried that GRC is still supporting SSL3, yes, I am, and I intend to continue doing so. I will certainly update the server next month or whenever Microsoft produces the fallback support. But it's really not necessary because, at least for GRC, there's no danger in falling back to 3.0 because, in the first place, I don't think anybody is ever going to perpetrate this attack, just for reasons of it being so difficult.

But here's the final point. Not only is it incredibly difficult, it's completely bogus because the absolute requirement to pull this off is that the attacker somehow get malicious code in the client running in the context of the site that is under attack so that queries are being issued to that site, and that it then do these thousands of queries in order to provide the opportunity for the attacker to break the end of the queries in order to generate the padding failures. Okay? And that's ridiculous.

Security Now! Transcript of Episode #478 Page 16 of 18 If anybody could get script running in the user's browser, even without any fault in the protocol, in SSL, even under TLS 1.2, the latest one, a client could easily use side channel leakage in order to communicate with somebody passively, not even an active attacker, a passive listener on the connection. The client knows what its cookies are, for example. That's something you can easily read in JavaScript is your HTTPS server-side authentication or your various cookies.

Pages:     | 1 | 2 || 4 |

Similar works:

«Questions about slopes of modular forms. Kevin Buzzard November 26, 2002 Abstract We formulate a conjecture which predicts, in many cases, the precise padic valuations of the eigenvalues of the Hecke operator Tp acting on spaces of classical modular forms. The conjecture has very concrete consequences in the classical theory, but can also be thought of as saying that there is a lot of unexplained symmetry in many of the Coleman-Mazur eigencurves. Introduction Let N ≥ 1 be a fixed integer,...»

«RevenueSA – Stamp Duty Document Guide Document Class: CONVEYANCE LAND Document Name: For Consideration Document Description: Residential/Primary Prod with Other Property Document Code: CLO Introduction This guide note explains how stamp duty is calculated on a conveyance of land with a Land Use Code (LUC) of Residential or Primary Production (or any of the 4 specific types of vacant land listed below) together with a conveyance of other property (that is not a prescribed good) where there is...»

«Paper Date Authors Key topics ACUTE CARE SALLY WILLIAMS PERFORMANCE MAY 2006 JAMES BUCHAN WORKFORCE Assessing the New NHS Consultant Contract A SOMETHING FOR SOMETHING DEAL? ASSESSING THE NEW NHS CONSULTANT CONTRACT A something for something deal? Sally Williams James Buchan © King’s Fund 2006 First published 2006 by the King’s Fund Charity registration number: 207401 All rights reserved, including the right of reproduction in whole or in part in any form. ISBN-10: 1 85717 547 6 ISBN-13:...»

«Friday, November 30, 2012 General Session #1 8am WLDR The session was called to order at 8:05am. Chair Virginia Brophy Achman welcomed those in attendance and invited everyone to introduce the association or organization that they were representing. Secretary Mickey Piscitelli made a motion to accept the minutes of the 2011 Annual Meeting which had been posted in the USATF online document library. Kathy Nary seconded. Unanimously accepted. WLDR Awards Mickey named the recipients of the two WLDR...»

«Copyright by Gregory Augustine Foran The Dissertation Committee for Gregory Augustine Foran certifies that this is the approved version of the following dissertation: “King Hereafter”: Macbeth and Apocalypse in the Stuart Discourse of Sovereignty Committee: John P. Rumrich, Supervisor Frank Whigham Eric S. Mallin Su Fang Ng Brian P. Levack “King Hereafter”: Macbeth and Apocalypse in the Stuart Discourse of Sovereignty by Gregory Augustine Foran, B.A.; M.A. Dissertation Presented to the...»

«POPULAR EXPRESSIONS AND SLUM VOCABULARY. COLLOQUIALISM IN THE PRESS LANGUAGE. Carmen Neamţu* Abstract A long time from now on the dominant style of the Romanian press will be a Latin one, with a waste of raciness, with ironies and stings, with a playful spirit and colorful expressions. These are features of our culture of existing and communicating: we could, at any time, sacrifice any BBClike rule for the sake of a pun. The journalist embraces this style, which refers to the live registers of...»

«DESIGNING SELF-MODIFYING AGENTS* FRANCES M.T. BRAZIER AND NIEK J.E. WIJNGAARDS Intelligent Interactive Distributed Systems Group, Faculty of Sciences, Vrije Universiteit Amsterdam, de Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands Email: {frances,niek}@cs.vu.nl URL: http://www.iids.org Abstract. Agents need to be able to adapt to changes in their environment. One way to achieve this, is to provide agents with the ability of self-modification. Self-modification requires reflection and...»

«Silva Fennica vol. 49 no. 2 article id 1280 SILVA FENNICA Category: research article www.silvafennica.fi ISSN-L 0037-5330 | ISSN 2242-4075 (Online) The Finnish Society of Forest Science Natural Resources Institute Finland Juha Laitila1, Tapio Ranta2, Antti Asikainen1, Eero Jäppinen2 and Olli-Jussi Korpinen2 The cost competitiveness of conifer stumps in the procurement of forest chips for fuel in Southern and Northern Finland Laitila J., Ranta T., Asikainen A., Jäppinen E., Korpinen O.-J....»

«Evaluation and Validation of Organic Materials for Advanced Stirling Convertors (ASCs): Overview Euy-Sik Eugene Shin1 Ohio Aerospace Institute, NASA Glenn Research Center, 21000 Brookpark Rd., MS 49-1, Cleveland, OH 44135de Various organic materials are used as essential parts in Stirling Convertors for their unique properties and functionalities such as bonding, potting, sealing, thread locking, insulation, and lubrication. More efficient Advanced Stirling Convertors (ASC) are being developed...»

«Humor in the collectivist Arab Middle East: The case of Lebanon Shahe S. Kazarian Abstract The Lebanese people are lovers of the social and the humorous, and the soul of their humor is manifest in their social gatherings, tales, civil and religious celebrations, songs, jokes, literature, theatre, cartoons, and spontaneous wit. In the present article, humor, Arabic ( fukaha), in the collectivist Lebanese culture is discussed with particular focus on comparisons with Western humor scholarship....»

«Denman Prospect Building and Siting Guidelines Building and Siting Guidelines Version 2.0 June 2016 © Capital Estate Developments 2015 Table of Contents Part One Using the Guidelines 1 1.1 Welcome – Creating Place 1 1.2 What do the Guidelines do? 1 1.3 Process to Approval 2 1.4 Compliance Bond 2 1.5 Landscape Contribution 3 1.6 Solar Requirement 4 1.7 Nature Strips and Territory Land 4 1.8 Regrading and Fill 4 1.9 Waste 5 1.10 Drainage and Stormwater 5 1.11 Other Issues to Consider 5 Part...»

«Felipe Serrano* Pensamiento post-keynesiano y pensamiento marxista TAL VEZ RESULTE CONVENIENTE empezar delimitando qué entendemos por pensamiento post-keynesiano y pensamiento marxista. Al proceder de esta manera quedarán fijados, al menos por lo que a mi intervención se refiere, los parámetros entre los que me moveré para realizar una reflexión comparativa entre ambas escuelas de pensamiento. La reflexión que se pretende, por otra parte, se centra en un punto muy concreto: el origen...»

<<  HOME   |    CONTACTS
2016 www.theses.xlibx.info - Theses, dissertations, documentation

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.