Professional Web Applications Themes

More on DRB & OpenSSL - Ruby

OK, I've tracked down my problem with DRb and OpenSSL a bit more; perhaps someone can help me out now, as I'm quickly getting out of my league. Here are test client and server scripts that will show the failure. To run them, you'll need the latest DRb from ruby CVS ([url]http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/lib/drb[/url]) installed (and of course the OpenSSL extension). s.rb: require 'drb' require 'drb/ssl' class Front def small puts "Called #small" "Hi!" end def large puts "Called #large" "a" * 1000 * 500 end end url = ARGV[0] or raise "You must supply the url" config = { :SSLCertName => ...

  1. #1

    Default More on DRB & OpenSSL

    OK, I've tracked down my problem with DRb and OpenSSL a bit more; perhaps
    someone can help me out now, as I'm quickly getting out of my league. Here
    are test client and server scripts that will show the failure. To run them,
    you'll need the latest DRb from ruby CVS
    ([url]http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/lib/drb[/url]) installed (and of
    course the OpenSSL extension).

    s.rb:

    require 'drb'
    require 'drb/ssl'

    class Front
    def small
    puts "Called #small"
    "Hi!"
    end

    def large
    puts "Called #large"
    "a" * 1000 * 500
    end
    end

    url = ARGV[0] or raise "You must supply the url"
    config = {
    :SSLCertName => [ ["C","US"], ["O","someplace"], ["CN", "Temporary"] ],
    :verbose => true
    }
    DRb.start_service(url, Front::new, config)
    puts "Listening on #{url}"
    DRb.thread.join

    c.rb:

    require 'drb'
    require 'drb/ssl'

    url = ARGV[0] or raise "You must supply the url"
    DRb.start_service
    front = DRbObject::new(nil, url)
    puts "Connected to #{url}"
    p front.small.size
    p front.large.size

    s.rb output:

    ntalbottproxytest:~$ ruby -vw s.rb drbssl://localhost:5777
    ruby 1.8.0 (2003-08-04) [i386-linux]
    .++++++++++++
    ....................++++++++++++
    Listening on drbssl://localhost:5777
    Called #small
    Called #large
    s.rb:23:in `join': Interrupt from s.rb:23

    c.rb output:

    ntalbottproxytest:~$ ruby -vw c.rb drbssl://localhost:5777
    ruby 1.8.0 (2003-08-04) [i386-linux]
    Connected to drbssl://localhost:5777
    3
    (Hangs until server is interrupted)
    500000

    If there's any other information I can provide, or anything else I can do to
    help debug this, please let me know. Also, if there are other places I
    should ask this question, please let me know that, too.

    Thanks,


    Nathaniel

    <:((><


    Nathaniel Talbott Guest

  2. #2

    Default Re: More on DRB & OpenSSL

    Nathaniel Talbott wrote:
    >OK, I've tracked down my problem with DRb and OpenSSL a bit more; perhaps
    >someone can help me out now, as I'm quickly getting out of my league. Here
    >are test client and server scripts that will show the failure. To run them,
    >you'll need the latest DRb from ruby CVS
    >([url]http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/lib/drb[/url]) installed (and of
    >course the OpenSSL extension).
    >
    >s.rb:
    >
    > require 'drb'
    > require 'drb/ssl'
    >
    > class Front
    > def small
    > puts "Called #small"
    > "Hi!"
    > end
    >
    > def large
    > puts "Called #large"
    > "a" * 1000 * 500
    > end
    > end
    >
    > url = ARGV[0] or raise "You must supply the url"
    > config = {
    > :SSLCertName => [ ["C","US"], ["O","someplace"], ["CN", "Temporary"] ],
    > :verbose => true
    > }
    > DRb.start_service(url, Front::new, config)
    > puts "Listening on #{url}"
    > DRb.thread.join
    >
    >c.rb:
    >
    > require 'drb'
    > require 'drb/ssl'
    >
    > url = ARGV[0] or raise "You must supply the url"
    > DRb.start_service
    > front = DRbObject::new(nil, url)
    > puts "Connected to #{url}"
    > p front.small.size
    > p front.large.size
    >
    >s.rb output:
    >
    > ntalbottproxytest:~$ ruby -vw s.rb drbssl://localhost:5777
    > ruby 1.8.0 (2003-08-04) [i386-linux]
    > .++++++++++++
    > ....................++++++++++++
    > Listening on drbssl://localhost:5777
    > Called #small
    > Called #large
    > s.rb:23:in `join': Interrupt from s.rb:23
    >
    >c.rb output:
    >
    > ntalbottproxytest:~$ ruby -vw c.rb drbssl://localhost:5777
    > ruby 1.8.0 (2003-08-04) [i386-linux]
    > Connected to drbssl://localhost:5777
    > 3
    > (Hangs until server is interrupted)
    > 500000
    >
    >If there's any other information I can provide, or anything else I can do to
    >help debug this, please let me know. Also, if there are other places I
    >should ask this question, please let me know that, too.
    >
    >Thanks,
    >
    >
    >Nathaniel
    >
    ><:((><
    >
    >
    I've noticed that there is always a strange silence on DRb questions. I
    wonder how many people really use it. I love it, well, I love what I
    know about it. The docs seems a little hard to come by.

    Michael


    Michael Garriss Guest

  3. #3

    Default Re: More on DRB & OpenSSL

    Michael Garriss [mailto:mgarrissearthlink.net] wrote:
    > I've noticed that there is always a strange silence on DRb
    > questions. I
    > wonder how many people really use it. I love it, well, I love what I
    > know about it. The docs seems a little hard to come by.
    You think docs are hard to come by for DRb, wait until you try using
    OpenSSL, or even better, OpenSSL with DRb. It's called reading the code :-/.
    Anyhow, DRb has been working great for me, and even the SSL part, with some
    figuring out, is doing OK. This problem, though, has me tearing my hair out.
    It's not very useful to only be able to send small messages across DRb.

    I'll let you know how it turns out.


    Nathaniel

    <:((><


    Nathaniel Talbott Guest

  4. #4

    Default Re: More on DRB & OpenSSL

    On Thu, 7 Aug 2003, Aredridel wrote:
    > > I've noticed that there is always a strange silence on DRb questions. I
    [...]
    > This is something we should change -- anyone want to work on an
    > initially wiki-based (english) doentation of dRB with me? It's
    I scratched together some notes at:

    [url]http://www.eng.cse.dmu.ac.uk/~hgs/ruby/dRuby/[/url]

    but I don't think I got everything right. Feel free to use this if
    it is of any use at all. That's why I wrote it somewhere visible.

    I've not got into SSL with this yet, I'm using SHA1's of
    (nonce + passwd)s to authenticate messages at the moment.
    >
    > Ari
    >
    Hugh



    Hugh Sasse Staff Elec Eng Guest

  5. #5

    Default Re: More on DRB & OpenSSL

    Hugh Sasse Staff Elec Eng [mailto:hgsdmu.ac.uk] wrote:
    > I scratched together some notes at:
    >
    > [url]http://www.eng.cse.dmu.ac.uk/~hgs/ruby/dRuby/[/url]
    >
    > but I don't think I got everything right. Feel free to
    > use this if it is of any use at all. That's why I wrote
    > it somewhere visible.
    I know, and I've been referring to it heavily. Thanks!

    BTW, is the RDoc on that page really for 1.3.8? Think you could update it? I
    suppose I could RDoc it myself, but I'd rather be lazy ;-)

    > I've not got into SSL with this yet, I'm using SHA1's of
    > (nonce + passwd)s to authenticate messages at the moment.
    Really? Can you tell me a bit more about that? Perhaps I can avoid SSL
    altogether.


    Nathaniel

    <:((><


    Nathaniel Talbott Guest

  6. #6

    Default Re: More on DRB & OpenSSL

    On Thu, 7 Aug 2003, Nathaniel Talbott wrote:
    > Hugh Sasse Staff Elec Eng [mailto:hgsdmu.ac.uk] wrote:
    >
    > > I scratched together some notes at:
    > >
    > > [url]http://www.eng.cse.dmu.ac.uk/~hgs/ruby/dRuby/[/url]
    >
    > I know, and I've been referring to it heavily. Thanks!
    Thanks, nice to know it is of some use.
    >
    > BTW, is the RDoc on that page really for 1.3.8? Think you could update it? I
    > suppose I could RDoc it myself, but I'd rather be lazy ;-)
    Yes, it is for dRuby-1.3.8 [not Ruby-1.3.8! I joined the ruby
    community circa 1.4.3 :-)] Thanks for the reminder, I'll update
    that.
    >
    >
    > > I've not got into SSL with this yet, I'm using SHA1's of
    > > (nonce + passwd)s to authenticate messages at the moment.
    >
    > Really? Can you tell me a bit more about that? Perhaps I can avoid SSL
    > altogether.
    It doesn't encrypt the message, but does a checksum with data that
    is never transmitted. Thus you can only forge the checksum if you
    have that data, so you can trust it. From the comments I wrote:

    # A nonce is a word that is used only once (according to concise
    # Oxford Dictionary.) The purpose is that it is generated, and a
    # password is added to it, and the hash of the whole string is
    # generated. Thus a hash is passed across the network so that the
    # password can be checked against this hash without having to send
    # the password across the network. This is used in CRAM-MD5, see
    # RFC2195 and RFC2104. CRAM == Challenge Response Authentication
    # Mechanism, MD5 is the message digest format. An Alternative to MD5
    # is SHA1.

    I'd rather not post my code, because of exposing weaknesses in it.
    These will exist because I find cryptographic systems full of
    subtleties, one of the reasons I have not got to grips with writing
    SSH code. This is slightly better, I suppose, than thinking I can
    write such things and have them secure!
    >
    >
    > Nathaniel
    >
    > <:((><
    >
    Hugh

    Hugh Sasse Staff Elec Eng Guest

  7. #7

    Default Re: More on DRB & OpenSSL

    On Thu, Aug 07, 2003 at 06:49:32PM +0900, Hugh Sasse Staff Elec Eng wrote:
    > It doesn't encrypt the message, but does a checksum with data that
    > is never transmitted. Thus you can only forge the checksum if you
    > have that data, so you can trust it. From the comments I wrote:
    >
    > # A nonce is a word that is used only once (according to concise
    > # Oxford Dictionary.) The purpose is that it is generated, and a
    > # password is added to it, and the hash of the whole string is
    > # generated. Thus a hash is passed across the network so that the
    > # password can be checked against this hash without having to send
    > # the password across the network.
    I'm not sure why you want a nonce here; just a hash of (message + shared
    secret) will do. But if you're paranoid you'll sign your objects with a
    timestamp as well.

    Try the code below. You can store session objects in a HTML input field like
    this, or if the objects are small enough they can be sent to the browser as
    a cookie!

    Regards,

    Brian.


    class SecureMarshall
    def initialize(secret, lifetime = 3600)
    require 'digest/md5'
    unless secret.is_a? String and secret.size >= 12
    raise "SecureMarshall secret must be at least 12 characters"
    end
    secret = secret
    lifetime = lifetime
    end

    def encode(obj)
    out = Marshal.dump([obj, Time.now.to_i + lifetime])
    [Marshal.dump([out, Digest::MD5::digest(out + secret)])]. \
    pack("m").gsub(/\n/,'') # base64 encode
    end

    def decode(key)
    raise TypeError, "Input must be a String" unless key.is_a? String
    out, hash = Marshal.load(key.unpack("m")[0])
    if Digest::MD5::digest(out + secret) != hash
    raise ArgumentError, "Invalid signature! Tampering with objects is forbidden"
    end
    obj, expiry = Marshal.load(out)
    if Time.now.to_i > expiry
    raise "Object expired"
    end
    obj
    end

    def freshen(key)
    encode(decode(key)) # re-sign the object with a new lifetime
    end
    end

    if __FILE__ == $0
    require 'test/unit'
    class MarshallTest < Test::Unit::TestCase
    def setup
    crypt = SecureMarshall.new("wibbly bibbly", 2)
    obj = ["fred", "jim"]
    end

    def test_decode
    a = crypt.encode(obj)
    b = crypt.decode(a)
    assert_equal(obj,b)
    end

    def test_wrong_key
    a = crypt.encode(obj)
    crypt2 = SecureMarshall.new("another secret", 2)
    assert_raises(ArgumentError) { crypt2.decode(a) }
    end

    def test_tamper
    a = crypt.encode(obj)
    a[25] += 1 # in the middle of the MD5 checksum
    assert_raises(ArgumentError) { crypt.decode(a) }
    end

    def test_lifetime
    a = crypt.encode(obj)
    sleep 4
    assert_raises(RuntimeError) { crypt.decode(a) }
    end

    def test_freshen
    a = crypt.encode(obj)
    4.times do
    sleep 1
    a = crypt.freshen(a)
    end
    b = crypt.decode(a)
    assert_equal(obj,b)
    end
    end
    end

    Brian Candler Guest

  8. #8

    Default Re: More on DRB & OpenSSL

    On Thu, 7 Aug 2003, Brian Candler wrote:

    > I'm not sure why you want a nonce here; just a hash of (message + shared
    > secret) will do. But if you're paranoid you'll sign your objects with a
    > timestamp as well.
    Initial authentication, and the nonce means they can't just forge
    the hashed passwd, and use that never-changing hash to authenticate
    themselves. I time out the nonce, so responses which are too
    late won't be accepted.
    >
    > Try the code below. You can store session objects in a HTML input field like
    > this, or if the objects are small enough they can be sent to the browser as
    > a cookie!
    >
    > Regards,
    >
    > Brian.
    >
    >
    > class SecureMarshall
    > def initialize(secret, lifetime = 3600)
    > require 'digest/md5'
    [...error checking...]
    > secret = secret
    > lifetime = lifetime
    > end
    >
    > def encode(obj)
    > out = Marshal.dump([obj, Time.now.to_i + lifetime])
    > [Marshal.dump([out, Digest::MD5::digest(out + secret)])]. \
    > pack("m").gsub(/\n/,'') # base64 encode
    > end
    [...]
    >
    This only works on one machine, and leaves the secret lying around
    in memory (secret). You can't really pass this object over the net
    without exposing the secret. This is the sort of subtlety that
    catches me out every time!

    Hugh


    Hugh Sasse Staff Elec Eng Guest

  9. #9

    Default Re: More on DRB & OpenSSL

    On Thu, 7 Aug 2003 07:58:29 +0900, Aredridel <aredridelnbtsc.org>
    wrote (more or less):
    >> I've noticed that there is always a strange silence on DRb questions. I
    >> wonder how many people really use it. I love it, well, I love what I
    >> know about it. The docs seems a little hard to come by.
    >
    >This is something we should change -- anyone want to work on an
    >initially wiki-based (english) doentation of dRB with me? It's
    >something I could enjoy delving deeply into, and I think that some
    >extensions could be useful as well.
    >
    >I'd host the wiki unless someone else really cares to -- I've a server
    >on a dual T-1 to offer, and a DS-3 coming in October. Bandwidth and CPU
    >are cheap ;-)
    I think this'd be a very Good Thing, especially if it the DRB homepage
    referred to it.

    I'm happy to be a wikignome for it.
    Cheers,
    Euan
    Gawnsoft: [url]http://www.gawnsoft.co.sr[/url]
    Symbian/Epoc wiki: [url]http://html.dnsalias.net:1122[/url]
    Smalltalk links (harvested from comp.lang.smalltalk) [url]http://html.dnsalias.net/gawnsoft/smalltalk[/url]
    Gawnsoft Guest

  10. #10

    Default Re: More on DRB & OpenSSL

    NAKAMURA, Hiroshi [mailto:nahikeynauts.com] wrote:
    > > From: "Nathaniel Talbott" <nathanielNOSPAMtalbott.ws>
    > > Sent: Thursday, August 07, 2003 7:45 AM
    >
    > > OK, I've tracked down my problem with DRb and OpenSSL a bit more;
    > > perhaps someone can help me out now, as I'm quickly getting
    > out of my
    > > league. Here are test client and server scripts that will show the
    > > failure. To run them, you'll need the latest DRb from ruby CVS
    > > ([url]http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/lib/drb[/url])
    > installed (and
    > > of course the OpenSSL extension).
    >
    > Reproduced on my cygwin box.
    > SSL client stacks at sysread after readable-check in
    > openssl/buffering.rb. I'm talking to gotoyuzo about this problem.
    Excellent! It's great to have somebody looking at this.

    Just for another data point, when I was doing my investigation, I saw it
    block both at the IO.select (as why says) and at the SSLSocket#sysread. Both
    times the blocking was happening on the client side.

    Thanks,


    Nathaniel

    <:((><


    Nathaniel Talbott Guest

  11. #11

    Default Re: More on DRB & OpenSSL

    why the lucky stiff [mailto:ruby-talkwhytheluckystiff.net] wrote:
    > For some reason the IO.select in openssl/buffering.rb is
    > stalling. It looks to be a problem in ossl.c.
    From looking at the code in ossl.c, I thought the problem might be in
    SSL_read, or the use of it. The doentation
    ([url]http://www.openssl.org/docs/ssl/SSL_read.html[/url]) seemed to be about as clear
    as mud about how that function works, though.

    > You can solve the problem for now by providing IO.select with
    > a timeout. I'm using 1.5 seconds below. (see following patch).
    This is excellent! I didn't know you could provide a timeout to IO#select.
    Now I can actually deploy my code. Thanks!

    > It's stopping on an IO#select on the 482nd iteration hitting
    > IO.select. This means that there is a current limitation in
    > the OpenSSL module of 481 * BLOCK_SIZE. It looks to me like
    > the Buffering module works fine, leaving the underlying
    > sysread, IO functions in ossl.c under inspection.
    >
    > Oh, and this problem is affecting the client only.
    That's what I observed as well.

    How do you find time to write about all that's cool in Ruby 1.8.0, work on
    YAML/Syck, research OpenSSL problems, and the million other things I'm sure
    you do? :-)

    Thanks,


    Nathaniel

    <:((><


    Nathaniel Talbott Guest

  12. #12

    Default Re: More on DRB & OpenSSL

    On Thu, 7 Aug 2003, Hugh Sasse Staff Elec Eng wrote:
    > On Thu, 7 Aug 2003, Nathaniel Talbott wrote:
    >
    > > BTW, is the RDoc on that page really for 1.3.8? Think you could update it? I
    > > suppose I could RDoc it myself, but I'd rather be lazy ;-)
    >
    > Yes, it is for dRuby-1.3.8 [not Ruby-1.3.8! I joined the ruby
    > community circa 1.4.3 :-)] Thanks for the reminder, I'll update
    > that.
    new revision: 1.12; previous revision: 1.11
    enter log message, terminated with single '.' or end of file:
    >> Added rdoc docs for druby 1.3.9 and 2.0.4
    >> .
    Hugh

    Hugh Sasse Staff Elec Eng Guest

  13. #13

    Default Re: More on DRB & OpenSSL

    Hugh Sasse Staff Elec Eng [mailto:hgsdmu.ac.uk] wrote:
    > On Thu, 7 Aug 2003, Nathaniel Talbott wrote:
    >
    > > Really? Can you tell me a bit more about that? Perhaps I
    > > can avoid SSL altogether.
    >
    > It doesn't encrypt the message, but does a checksum with data
    > that is never transmitted. Thus you can only forge the
    > checksum if you have that data, so you can trust it.
    Ah... that isn't enough for me. I want information hiding as well.

    > From the comments I wrote:
    >
    > # A nonce is a word that is used only once (according to concise
    > # Oxford Dictionary.) The purpose is that it is generated, and a
    > # password is added to it, and the hash of the whole string is
    > # generated. Thus a hash is passed across the network so that the
    > # password can be checked against this hash without having to send
    > # the password across the network. This is used in CRAM-MD5, see
    > # RFC2195 and RFC2104. CRAM == Challenge Response Authentication
    > # Mechanism, MD5 is the message digest format. An Alternative to MD5
    > # is SHA1.
    I still don't quite understand... is the nonce generated somehow? If so, how
    do both sides use the same nonce?

    > I'd rather not post my code, because of exposing weaknesses
    > in it. These will exist because I find cryptographic systems
    > full of subtleties, one of the reasons I have not got to
    > grips with writing SSH code. This is slightly better, I
    > suppose, than thinking I can write such things and have them secure!
    Security through obscurity, eh? ;-)

    I can understand your sentiments. Actually, I was thinking about putting
    together a 'locked-down' version of DRb, and submitting it for peer review.
    As Bruce Schneier said (pardon the long quote),

    "Security engineering is not like any other type of
    engineering. An engineer who's building something
    will spend all night to make it work.
    That's quintessentially what a good hack is. It
    works, it's functional. In a normal product, it's
    what it does that's impressive.

    "But security products are not useful because of
    what they do; they're useful precisely because of
    what they don't allow to happen. Security has
    nothing to do with functionality.

    "If you were to build a word processor and
    wanted to know if it printed, you could plug a
    printer in, push the print button, and see if a
    printed doent came out. If you're building a
    encryption product, you can put a file in, watch
    it encrypt and decrypt. You know it works, but
    you have no idea if it's secure or not. And that's
    a big deal. What it means is that you can't tell if
    a product's secure simply by examining it, simply
    by running it through functional tests.

    "No amount of beta testing will find a security
    flaw. In many ways, security engineering is similar
    to safety engineering. But there is a difference.
    Safety engineering has to do with making
    something work in the presence of random or
    transient faults (i.e., Murphy's Law). Security
    programming involves making sure something
    works even in the presence of a malicious adversary
    who will make exactly the wrong thing
    fail at exactly the wrong time and do it again,
    and again, and again, and again to break the security.
    That's why I call it programming Satan's
    computer. You program a computer with the assumption
    that a malicious adversary intent on
    defeating the system is living inside the system.
    Security is supposed to provide some way to encapsulate
    him."

    from "Security in the Real World: How to Evaluate Security Technology"
    by Bruce Schneier
    [url]http://www.counterpane.com/real-world-security.pdf[/url]

    Which scares me a bit, since it means the software I write can work great
    for my users, and yet be totally insecure - and that insecurity won't be
    discovered either until it's compromised, or until I discover it myself.

    So my basic strategy at this point is to assume that user's passwords are
    insecure, and thus carefully lock down my server-side interface so that
    remote users can't do anything unsafe on the server. SSL is basically just
    for information hiding, so that the data that's being passed can't be
    trivially sniffed on the network. The data is of the type that shouldn't be
    shared, but if it were somehow decrypted, there aren't any corporate secrets
    or anything.

    As for locking down the server-side interface, I've done a couple of things.
    First of all, I'm running at $SAFE = 1, meaning that tainted strings can't
    be used for insecure operations. Second, I've locked down DRb such that only
    methods that I specifically allow may be called, as opposed to the normal
    strategy of any method except those you specifically deny (i.e. make
    private). I plan to keep an eye on it as I continue, and see if there's
    anything else I need to do.

    One thing I'd love to see happen is an easy to use, easy to understand, well
    doented suite of ruby security libraries and tools built around the
    OpenSSL library, so that security is easy(er) to set up and use. Currently
    it's tempting to do something less than secure because it's quite complex to
    get something secure going. For instance, I toyed with setting up a
    certificate authority and distributing signed certificates to each client of
    my app, but the doentation and tools for doing that are, at least to this
    idiot, obscure, convoluted and complex. It'd be nice if Ruby emerged as a
    solution for doing this simply and well. I know that there are those that
    fear making these things too easy, as some will be lulled in to a false
    sense of security, but I can't see it being worse than it is now, with the
    issue all too often ignored.

    Anyhow, sorry for the long email. If anyone has any further ideas for how to
    secure things, I'm all ears.


    Nathaniel

    <:((><


    Nathaniel Talbott Guest

  14. #14

    Default Re: More on DRB & OpenSSL

    On Thu, 7 Aug 2003, Nathaniel Talbott wrote:
    > Hugh Sasse Staff Elec Eng [mailto:hgsdmu.ac.uk] wrote:
    >
    > > It doesn't encrypt the message, but does a checksum with data
    >
    > Ah... that isn't enough for me. I want information hiding as well.
    >
    >
    > > From the comments I wrote:
    > >
    >
    > I still don't quite understand... is the nonce generated somehow? If so, how
    > do both sides use the same nonce?
    >
    Server generates nonce (as a function of whatever. ($$, time, current
    England cricket score, or something)).
    Client sees nonce (world sees nonce, too)
    Client sticks passwd on the end of nonce, and hashes the whole thing.
    Client sends hash back to server.
    Server sees response from client, and reconstructs the hash in the
    same way as the client. If they agree all is OK.
    The hash function makes it hard for Eve to guess the passwd, and
    impossible to directly calculate it because information is
    destroyed.
    >
    > > I'd rather not post my code, because of exposing weaknesses
    > > in it. These will exist because I find cryptographic systems
    > > full of subtleties, one of the reasons I have not got to
    > > grips with writing SSH code. This is slightly better, I
    > > suppose, than thinking I can write such things and have them secure!
    >
    > Security through obscurity, eh? ;-)
    Well, not entirely. I know that obscurity on its own is rubbish.
    It's more like not advertising that you use a lock which others know
    to be weak. The obscurity is not better than thinking I can invent
    crypto systems. The avoidance of encryption is better than such
    naivety. I think. And I could be wrong; there always seems to be one
    more level of subtlety. But there are areas where the data cannot be sent
    in plain sight, so this is not universally applicable.
    > I can understand your sentiments. Actually, I was thinking about putting
    > together a 'locked-down' version of DRb, and submitting it for peer review.
    > As Bruce Schneier said (pardon the long quote),
    "[...]
    > it encrypt and decrypt. You know it works, but
    > you have no idea if it's secure or not. And that's
    > a big deal. What it means is that you can't tell if
    [...]
    > transient faults (i.e., Murphy's Law). Security
    > programming involves making sure something
    > works even in the presence of a malicious adversary
    > who will make exactly the wrong thing
    > fail at exactly the wrong time and do it again,
    > and again, and again, and again to break the security.
    And HOW do you test (first) for this? :-)

    [...]"
    > by Bruce Schneier
    > [url]http://www.counterpane.com/real-world-security.pdf[/url]
    >
    > Which scares me a bit, since it means the software I write can work great
    > for my users, and yet be totally insecure - and that insecurity won't be
    > discovered either until it's compromised, or until I discover it myself.
    Exactly.
    >
    >
    > One thing I'd love to see happen is an easy to use, easy to understand, well
    > doented suite of ruby security libraries and tools built around the
    > OpenSSL library, so that security is easy(er) to set up and use. Currently
    Yes. There are still subtleties, though....
    [...]
    > my app, but the doentation and tools for doing that are, at least to this
    > idiot, obscure, convoluted and complex. It'd be nice if Ruby emerged as a
    > solution for doing this simply and well. I know that there are those that
    > fear making these things too easy, as some will be lulled in to a false
    > sense of security, but I can't see it being worse than it is now, with the
    > issue all too often ignored.
    And there are plenty of governments who object to people being able
    to provide security as well. This just adds to the complexity. Yet
    another reason why I tried to work without actual cryptography.
    > Anyhow, sorry for the long email. If anyone has any further ideas
    > for how to secure things, I'm all ears.
    >
    >
    > Nathaniel
    >
    > <:((><
    >
    Hugh
    >
    >
    Hugh Sasse Staff Elec Eng Guest

  15. #15

    Default Re: More on DRB & OpenSSL

    On Fri, 8 Aug 2003, Brian Candler wrote:
    > On Fri, Aug 08, 2003 at 12:03:01AM +0900, Hugh Sasse Staff Elec Eng wrote:
    (what was effectively a crayon sketch of CRAM MD5, roughly)
    >
    > OK. That lets B authenticate A. The main weakness is that if the nonce and
    So I have them both ways.
    > response are sniffed, the password is subject to an off-line dictionary
    > attack.
    Agreed. I don't know a good way round this. I expect any method
    based on Hashing has this misfeature. SHA is said to be better than
    MD5 in the RFCs, small help though that is.
    >
    > And of course, this exchange does not protect the rest of the data in
    > transit. An active attacker could allow this authentication exchange to take
    > place, and then substitute the subsequent session data with something else.
    Which is why I keep changing the nonce for each bit of dialogue
    between the machines, try to ensure (Time(),Date()) that it never
    repeats, and make the plain text part of the input to the hasher, so
    its authenticity gets tested when the hash is checked.

    I'm sure I've missed something, though. The phrase "cunning plan"
    springs to mind, unfortunately.
    >
    > Regards,
    >
    > Brian.
    >
    Hugh
    >
    Hugh Sasse Staff Elec Eng Guest

  16. #16

    Default Re: More on DRB & OpenSSL

    On Fri, 8 Aug 2003, Brian Candler wrote:
    > > > response are sniffed, the password is subject to an off-line dictionary
    > > > attack.
    > >
    > > Agreed. I don't know a good way round this. I expect any method
    > > based on Hashing has this misfeature. SHA is said to be better than
    > > MD5 in the RFCs, small help though that is.
    >
    > No, that's not it. It's not a weakness of the hash, it's a weakness of your
    > challenge-response protocol design. However it's fine as long as you choose
    Yes, I see what you mean. Well, it's not my design really, I
    implemented what's in the RFCs cited earlier. I wouldn't design my
    own, I've learned that much! :-)
    > a strong password (say a true random 128 bit value) which cannot be
    > brute-forced.
    >
    > Otherwise you go to a different system altogether - such as public key
    > authentication.
    OK, I should look into that further, but isn't that subject to
    similar attacks: not dictionary, but the parallel computer based
    ones, like DES cracking challenges people set up. Reply off list if
    you wish, this could bore the legs of some readers and is getting
    less Ruby specific! :-)

    [....]
    >
    > Right, so you're saying that you calculate the hash over the payload *and*
    > the nonce:
    >
    > [ payload ] [nonce] [hash]
    > ^^^^^^^^^^^^^^^^^^^
    > ^ Hash of (payload + nonce + secret)
    Yes....
    >
    > But once you've done that, you don't need the nonce in the first place,
    > which is the point I was trying to make before.
    The nonce gives timeout information, and prevents othere injecting
    data into the system. Even if they can forge something convincing
    they need the right nonce to be able to do it NOW.
    >
    > The nonce could still be useful to prevent replay attacks; that's where the
    That's the sort of thing I mean.
    > attacker simply resends a valid signed packet at a later time. But using a
    > nonce for that purpose requires that every packet is sent in response to a
    Agreed, unless the packet sent is a challenge in the other direction.
    > challenge. A better mechanism is to use timestamps or sequence numbers on
    > your packets.
    But can't sequential numbers be forged easily? (I use time as part
    of the nonce, and time alone could be forged: people have had to put
    security features into NTP to stop people attacking "time itself"
    [There's a B movie in there somewhere!]).
    >
    > That's what the SecureMarshall class I posted did:
    >
    > [ payload ] [ expiry time ] [ hash ]
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > ^ Hash of (payload + expiry + secret)
    >
    > You can receive incoming packets asynchronously, and know that they are
    That can be done with auth in the other direction, can't it?

    [...]
    >
    > You still have the possibility of replay attack within the timestamp window.
    > It's horses for courses. The above mechanism works well for me - I can send
    That's it. The point I've not been making clearly is that one can
    provide a level of security and one may think it is good enough. But
    there are always subtleties, and I think that it boils down to how
    many subtleties one is prepared to consider. The oft-cited thing
    about "lines of code you don't write can't have bugs" suggests a
    parallel: only messages you never have to send will be secure.
    It sounds to me as though I may have things about right. Though I
    have still probably missed something! :-)
    > objects off to a completely untrusted person to return back to me at a later
    > stage (e.g. a subsequent POST of a HTML form), knowing that they have not
    > been tampered with.
    yes, hashes are particularly good for that.
    >
    > Regards,
    >
    > Brian.
    >
    >
    Thank you,
    Hugh

    Hugh Sasse Staff Elec Eng Guest

  17. #17

    Default Re: More on DRB & OpenSSL

    On Fri, 8 Aug 2003, Brian Candler wrote:
    > On Fri, Aug 08, 2003 at 06:36:59PM +0900, Hugh Sasse Staff Elec Eng wrote:
    > > > Otherwise you go to a different system altogether - such as public key
    > > > authentication.
    > >
    > > OK, I should look into that further, but isn't that subject to
    > > similar attacks: not dictionary, but the parallel computer based
    > > ones, like DES cracking challenges people set up. Reply off list if
    > > you wish, this could bore the legs of some readers and is getting
    > > less Ruby specific! :-)
    >
    > I guess you're right. Bruce Schneier's "Applied Cryptography" is a highly
    > recommended read.
    >
    > > > Right, so you're saying that you calculate the hash over the payload *and*
    > > > the nonce:
    > > >
    > > > [ payload ] [nonce] [hash]
    > > > ^^^^^^^^^^^^^^^^^^^
    > > > ^ Hash of (payload + nonce + secret)
    > >
    > > Yes....
    > > >
    > > > But once you've done that, you don't need the nonce in the first place,
    > > > which is the point I was trying to make before.
    > >
    > > The nonce gives timeout information, and prevents othere injecting
    > > data into the system. Even if they can forge something convincing
    > > they need the right nonce to be able to do it NOW.
    >
    > Then it is not a nonce. A nonce would be a random meaningless string - which
    > could of course include the current date/time as part of ensuring it is not
    That's what it is...
    > repeated. But if you are *extracting* the date/time out of that string and
    And that is what I am not doing. The end that served the nonce
    'knows' when to expire it.
    > using it to decide whether you will accept the packet or not, then it's a
    > timestamp.
    OK, I see what you mean. I think the Concise Oxford Dictionary
    definition would stil encompass that, but I won't press the
    point!:-)
    >
    [...]
    > > But can't sequential numbers be forged easily?
    >
    > You can't forge anything which is under the protection of the signature
    > (i.e. included as part of the hash in the shared-secret algorithm we're
    > discussing), because to do so you would need to know the secret.
    Good point. Well, I'll stick with the nonces for now, I need them
    for initial setup, and code re-use is good.
    >
    >
    > Regards,
    >
    > Brian.
    >
    >
    Thank you for your input on this.
    Hugh

    Hugh Sasse Staff Elec Eng Guest

Similar Threads

  1. Ruby/OpenSSL bug?
    By Nathaniel Talbott in forum Ruby
    Replies: 3
    Last Post: November 12th, 07:17 PM
  2. OpenSSL
    By Brian Murphy-Dye in forum Ruby
    Replies: 0
    Last Post: October 22nd, 05:19 PM
  3. openSSL on SCO 5.0.5
    By ajonas in forum SCO
    Replies: 1
    Last Post: August 23rd, 03:54 AM
  4. OpenSSL/drb problem
    By Nathaniel Talbott in forum Ruby
    Replies: 1
    Last Post: August 6th, 05:40 PM
  5. OpenSSL & Ruby 1.8
    By Nathaniel Talbott in forum Ruby
    Replies: 0
    Last Post: July 31st, 09:12 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139