Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 44

Thread: Anybody know how https *really* works? I didn't think so

  1. #21
    Ari Silverstein
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Mon, 1 Nov 2010 10:08:49 -0700 (PDT), RayLopez99 wrote:

    > That's the second time I've used please in this post
    > and twice too many.


    See what I mean? Pants on fire there, assclown.
    --
    http://tr.im/1fa3

  2. #22
    FromTheRafters
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    "RayLopez99" <raylopez88@gmail.com> wrote in message
    news:10194b0e-7873-4931-b5ec-d8d7d99f939d@y23g2000yqd.googlegroups.com...
    On Nov 1, 4:13 pm, "FromTheRafters" <erra...@nomail.afraid.org> wrote:

    >
    > >> Does this make sense?

    >
    > > No. Private keys are never shared with anyone.

    >
    > > Further reading:
    > >http://www.ourshop.com/resources/ssl.html

    >
    > It may take a while, but eventually he will understand that the data
    > is
    > "covered" only in transit just as with TPM supported disk encryption
    > it
    > is only covered at rest.


    Explain please in simple words. You are saying encryption of https
    data is only done in transit? Why/how? To be more explicit: C
    (client) --> S (intermediary) --> Z (endpoint/host server): you are
    saying encryption is only at the "-->" in between the points, C, S and
    Z? That is, at the servers C,S,Z you can read the data packets in
    plaintext, but when they transmit the data stream they become
    encrypted ciphertext?

    ***
    The client and server have a trust relationship, they agree on a keyset
    and the data is encrypted by the client, sent out on the wire, received
    by the server, and decrypted by the key. If it needs to do it again (not
    the final destination), another trust relationship is set up btween the
    server and the next step and the process may be repeated (new
    relationships, new keys, no transitive trust). The idea was to have the
    data covered so that sniffing or otherwise capturing packets enroute
    would not have value to the interloper (the encryption security is as
    good as the key management - if the interloper (you don't have a trust
    relationship with) doesn't have the key, he cannot convert the
    ciphertext to plaintext.

    You are *trusting* all of the SSL capable servers with your data unless
    you "cover" your data for the entire source to destination trip.
    ***

    If so, this does make Jason Keats explanation work, but I would be
    very surprised if this is so. Why would anybody design an algorithm
    that decrypts as soon as it reaches a server?

    ***
    Those whom are only concerned with the security (integrity) of the
    point-to-point communications.

    Think of the old can-to-can voice communication, and someone
    eavesdropping with a tap on the string. You still want to be able to
    speak into one end and hear from the other, but you want the
    eavesdropper to get nothing intelligible. If your can-to-can connection
    is only one part of a relay communication network, you wouldn't be
    concerned about the relay personnel actually having access to that
    information uncovered. If you were concerned about that, then end-to-end
    coverage is what you really want.
    ***



  3. #23
    Jason Keats
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    RayLopez99 wrote:
    > On Nov 1, 4:13 pm, "FromTheRafters"<erra...@nomail.afraid.org> wrote:
    >
    >>
    >>>> Does this make sense?

    >>
    >>> No. Private keys are never shared with anyone.

    >>
    >>> Further reading:
    >>> http://www.ourshop.com/resources/ssl.html

    >>
    >> It may take a while, but eventually he will understand that the data is
    >> "covered" only in transit just as with TPM supported disk encryption it
    >> is only covered at rest.

    >
    > Explain please in simple words. You are saying encryption of https
    > data is only done in transit? Why/how? To be more explicit: C
    > (client) --> S (intermediary) --> Z (endpoint/host server): you are
    > saying encryption is only at the "-->" in between the points, C, S and
    > Z? That is, at the servers C,S,Z you can read the data packets in
    > plaintext, but when they transmit the data stream they become
    > encrypted ciphertext?


    Yes, that's correct - because C used S's URL, not Z's.

    > If so, this does make Jason Keats explanation work, but I would be
    > very surprised if this is so. Why would anybody design an algorithm
    > that decrypts as soon as it reaches a server?


    The protocol doesn't decrypt as soon as soon as it reaches _any_ server,
    only when it reaches _the_ server addressed in the URL.

  4. #24
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 2, 3:10*am, "FromTheRafters" <erra...@nomail.afraid.org> wrote:
    > "RayLopez99" <raylope...@gmail.com> wrote in message
    >
    > news:10194b0e-7873-4931-b5ec-d8d7d99f939d@y23g2000yqd.googlegroups.com...
    > On Nov 1, 4:13 pm, "FromTheRafters" <erra...@nomail.afraid.org> wrote:
    >
    >
    >
    > > >> Does this make sense?

    >
    > > > No. Private keys are never shared with anyone.

    >
    > > > Further reading:
    > > >http://www.ourshop.com/resources/ssl.html

    >
    > > It may take a while, but eventually he will understand that the data
    > > is
    > > "covered" only in transit just as with TPM supported disk encryption
    > > it
    > > is only covered at rest.

    >
    > Explain please in simple words. *You are saying encryption of https
    > data is only done in transit? *Why/how? *To be more explicit: *C
    > (client) --> S (intermediary) --> Z (endpoint/host server): *you are
    > saying encryption is only at the "-->" in between the points, C, S and
    > Z? *That is, at the servers C,S,Z you can read the data packets in
    > plaintext, but when they transmit the data stream they become
    > encrypted ciphertext?
    >
    > ***
    > The client and server have a trust relationship, they agree on a keyset
    > and the data is encrypted by the client, sent out on the wire, received
    > by the server, and decrypted by the key. If it needs to do it again (not
    > the final destination), another trust relationship is set up btween the
    > server and the next step and the process may be repeated (new
    > relationships, new keys, no transitive trust). The idea was to have the
    > data covered so that sniffing or otherwise capturing packets enroute
    > would not have value to the interloper (the encryption security is as
    > good as the key management - if the interloper (you don't have a trust
    > relationship with) doesn't have the key, he cannot convert the
    > ciphertext to plaintext.
    >


    Thanks. OK, but who sets up the 'new keys', 'new relationships'? It
    has to be done by somebody using new SSL certificates, not the
    original one used by C?

    Here is where I'm going: C wants to send to Z. It types in Z's URL
    using an SSL certificate. By the nature of the internet, inbetween C
    and Z there are always other servers that act as relays, call one of
    them 'S'. Is it possible for them to use 'new keys', 'new
    relationships' that would compromise the message from C to Z? Unknown
    to C? I don't think so--or I can't see how. That is, C would have to
    send a message to 'S', not 'Z'. But at that point, we are arguing
    over semantics--'S' now *is* 'Z'! Of course if S wants to send to Z,
    that will mean S can read the message--but that's just plain stupid
    semantics.

    Please explain if it's possible for C to send to Z, then, if there's
    an intermediate SOAP server S, unknown to C (maybe not unknown, but
    perhaps unsuspected for a security risk) whether S can decrypt the
    message if C has typed in Z's URL. Unless--and maybe this is
    possible--C types in Z's URL but the program--behind the scenes--
    changes Z's URL to S! Why would it do that--can it do that?

    RL

  5. #25
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 2, 3:33*am, Jason Keats <jke...@melbpcDeleteThis.org.au> wrote:

    > > Explain please in simple words. *You are saying encryption of https
    > > data is only done in transit? *Why/how? *To be more explicit: *C
    > > (client) --> *S (intermediary) --> *Z (endpoint/host server): *you are
    > > saying encryption is only at the "-->" in between the points, C, S and
    > > Z? *That is, at the servers C,S,Z you can read the data packets in
    > > plaintext, but when they transmit the data stream they become
    > > encrypted ciphertext?

    >
    > Yes, that's correct - because C used S's URL, not Z's.
    >
    > > If so, this does make Jason Keats explanation work, but I would be
    > > very surprised if this is so. *Why would anybody design an algorithm
    > > that decrypts as soon as it reaches a server?

    >
    > The protocol doesn't decrypt as soon as soon as it reaches _any_ server,
    > only when it reaches _the_ server addressed in the URL.


    My same question to you as to FromTheRafters (repeated below). I
    don't see how--even accepting your explanation--if C uses Z's URL this
    can happen--unless, C uses S's URL rather than Z 'without knowing
    it' (that is, it is substituted by either the program or by the HTTPS
    public key mechanism itself unknown to C). Does this 'unknown' use
    happen in practice? Is this the infamous "Cross-site scripting (XSS)"
    attack? Is this how S becomes Z?

    RL

    > ***
    > The client and server have a trust relationship, they agree on a keyset
    > and the data is encrypted by the client, sent out on the wire, received
    > by the server, and decrypted by the key. If it needs to do it again (not
    > the final destination), another trust relationship is set up btween the
    > server and the next step and the process may be repeated (new
    > relationships, new keys, no transitive trust). The idea was to have the
    > data covered so that sniffing or otherwise capturing packets enroute
    > would not have value to the interloper (the encryption security is as
    > good as the key management - if the interloper (you don't have a trust
    > relationship with) doesn't have the key, he cannot convert the
    > ciphertext to plaintext.
    >


    Thanks. OK, but who sets up the 'new keys', 'new relationships'? It
    has to be done by somebody using new SSL certificates, not the
    original one used by C?

    Here is where I'm going: C wants to send to Z. It types in Z's URL
    using an SSL certificate. By the nature of the internet, inbetween C
    and Z there are always other servers that act as relays, call one of
    them 'S'. Is it possible for them to use 'new keys', 'new
    relationships' that would compromise the message from C to Z? Unknown
    to C? I don't think so--or I can't see how. That is, C would have to
    send a message to 'S', not 'Z'. But at that point, we are arguing
    over semantics--'S' now *is* 'Z'! Of course if S wants to send to Z,
    that will mean S can read the message--but that's just plain stupid
    semantics.

    Please explain if it's possible for C to send to Z, then, if there's
    an intermediate SOAP server S, unknown to C (maybe not unknown, but
    perhaps unsuspected for a security risk) whether S can decrypt the
    message if C has typed in Z's URL. Unless--and maybe this is
    possible--C types in Z's URL but the program--behind the scenes--
    changes Z's URL to S! Why would it do that--can it do that?


    RL

  6. #26
    unruh
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    ["Followup-To:" header set to alt.computer.security.]
    On 2010-11-02, RayLopez99 <raylopez88@gmail.com> wrote:
    > On Nov 2, 3:10?am, "FromTheRafters" <erra...@nomail.afraid.org> wrote:
    >> "RayLopez99" <raylope...@gmail.com> wrote in message

    ....
    > Please explain if it's possible for C to send to Z, then, if there's
    > an intermediate SOAP server S, unknown to C (maybe not unknown, but
    > perhaps unsuspected for a security risk) whether S can decrypt the
    > message if C has typed in Z's URL. Unless--and maybe this is
    > possible--C types in Z's URL but the program--behind the scenes--
    > changes Z's URL to S! Why would it do that--can it do that?

    Your system contacts Z and asks for a public key. It then checks the
    signing authority of that public key against the set of signing
    authorities it has in its list. If it checks out, it then uses Z's
    public key to encrypt a random symmentric key, and encrypts the message with
    that symmetric key, and sends the encrypted symmetric key and the
    encrypted message out.
    Thus any S would need to know Z's private key,

    Now, if S could act as a man in the middle, and persuade your machine
    that S's public key is really Z's public key, then of course S could
    read your transmission. That is prevented by the "web of trust" -- the
    fact that you trust the signing authority who stated that Z's key really
    was Z's key. Of course if you do not have the signing authority's public
    key in your system or S has persuaded you (or your distro) to put a bogus public key for
    that signing authority into your system, the game is up.
    >O

    So no, without a lot of work, intermediate machines cannot read your SSL
    stuff sent to Z, or you ignored the warning from your browser that it
    did not know the signing authority for the key you are using.

    > RL


  7. #27
    Jason Keats
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    RayLopez99 wrote:
    >
    > Please explain if it's possible for C to send to Z, then, if there's
    > an intermediate SOAP server S, unknown to C (maybe not unknown, but
    > perhaps unsuspected for a security risk) whether S can decrypt the
    > message if C has typed in Z's URL.


    The answer is still no!

  8. #28
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 2, 12:03*pm, unruh <un...@wormhole.physics.ubc.ca> wrote:

    >
    > Your system contacts Z and asks for a public key. It then checks the
    > signing authority of that public key against the set of signing
    > authorities it has in its list. If it checks out, it then uses Z's
    > public key to encrypt a random symmentric key, and encrypts the message with
    > that symmetric key, and sends the encrypted symmetric key and the
    > encrypted message out.
    > Thus any S would need to know Z's private key, *
    >
    > Now, if S could act as *a man in the middle, and persuade *your machine
    > that S's public key is really Z's public key, then of course S could
    > read your transmission. That is prevented by the "web of trust" -- the
    > fact that you trust the signing authority who stated that Z's key really
    > was Z's key. Of course if you do not have the signing authority's public
    > key in your system or S has persuaded you (or your distro) to put a boguspublic key for
    > that signing authority into your system, the game is up.>O
    >
    > So no, without a lot of work, intermediate machines cannot read your SSL
    > stuff sent to Z, or you ignored the warning from your browser that it
    > did not know the signing authority for the key you are using.
    >


    Unruh--you are probably late to this thread. The issue here is not
    spoofing so much as the statement by others in this thread that S (the
    intermediary) *CAN* read your SSL stuff. How it does this is the
    question.

    One proposal (and I have yet to see this explicitly): for SSL
    encrypted message routing to work, when involving intermediaries like
    SOAP servers (like S in our A to S to Z transmission of a SSL
    message), S the intermediary *must* be able to decrypt the message.
    It contacts the relevant endpoint, Z, gets permission to decrypt, and
    does decrypt. Then it routes the message using the headers
    (unencrypted). Before it transmits the message, S will of course
    encrypt it again, so while the message is in transit nobody can read
    it. But S itself can (and must) read the message for the transmission
    to work.

    Can anybody confirm this? I've not seen this on the net, but it's a
    logical inference from what I have seen.

    RL

  9. #29
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 2, 2:29*pm, Jason Keats <jke...@melbpcDeleteThis.org.au> wrote:
    > RayLopez99 wrote:
    >
    > > Please explain if it's possible for C to send to Z, then, if there's
    > > an intermediate SOAP server S, unknown to C (maybe not unknown, but
    > > perhaps unsuspected for a security risk) whether S can decrypt the
    > > message if C has typed in Z's URL.

    >
    > The answer is still no!


    Why? See my question to Unruh. Don't crap out now Jason, we are close
    to the finish line and you've come so far! Future readers of this
    thread, and it's novel as I've not seen this topic elsewhere, will
    wonder what the answer is.

    RL

    keywords: SSL does not work, SSL does not encrypt, SSL is not safe,
    TLS does not work, TLS is not safe, TLS does not encrypt, message
    security not 100% not complete not guaranteed with SSL or TLS, people
    can read your messages with SSL certificate or TLS certificates.


  10. #30
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 2, 12:03*pm, unruh <un...@wormhole.physics.ubc.ca> wrote:

    >
    > Now, if S could act as *a man in the middle, and persuade *your machine
    > that S's public key is really Z's public key, then of course S could
    > read your transmission. That is prevented by the "web of trust" -- the
    > fact that you trust the signing authority who stated that Z's key really
    > was Z's key. Of course if you do not have the signing authority's public
    > key in your system or S has persuaded you (or your distro) to put a boguspublic key for
    > that signing authority into your system, the game is up.>O
    >
    > So no, without a lot of work, intermediate machines cannot read your SSL
    > stuff sent to Z, or you ignored the warning from your browser that it
    > did not know the signing authority for the key you are using.
    >


    Not sure if my reply got through, so I'll try and paraphrase it again.

    The issue is how S (C --> S --> Z) *can* read your SSL stuff. How?
    Microsoft says it's possible (see the link and blurb earlier in this
    thread).

    One idea: S has permission to read and decrypt the SSL stuff from C
    and/or Z--so it's not 'illegal'. My question: when does this happen?
    Does it happen only in 'rare' cases where the program needs to use an
    intermediary SOAP server like S to get some additional information
    (such as a mashup, if you know how they work), or, does this happen
    *everytime* there is a transmission using several connecting points
    (servers) in between C and Z? This latter scenario is what scares
    me. I can deal with mashups explicitly being given permission to
    decrypt, but I cannot deal with every intermediary server being able
    to decrypt a SSL or TLS message--but maybe this latter case is how in
    fact things work.

    RL

  11. #31
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 3, 1:54*pm, RayLopez99 <raylope...@gmail.com> wrote:
    > On Nov 2, 2:29*pm, Jason Keats <jke...@melbpcDeleteThis.org.au> wrote:
    >
    > > RayLopez99 wrote:

    >
    > > > Please explain if it's possible for C to send to Z, then, if there's
    > > > an intermediate SOAP server S, unknown to C (maybe not unknown, but
    > > > perhaps unsuspected for a security risk) whether S can decrypt the
    > > > message if C has typed in Z's URL.

    >
    > > The answer is still no!

    >
    > Why? *See my question to Unruh. Don't crap out now Jason, we are close
    > to the finish line and you've come so far! *Future readers of this
    > thread, and it's novel as I've not seen this topic elsewhere, will
    > wonder what the answer is.
    >
    > RL
    >
    > keywords: *SSL does not work, SSL does not encrypt, *SSL is not safe,
    > TLS does not work, TLS is not safe, TLS does not encrypt, message
    > security not 100% not complete not guaranteed with SSL or TLS, people
    > can read your messages with SSL certificate or TLS certificates.


    Further, Microsoft says that S can decrypt the message. Why do they
    say that? Is this a case where a "mashup" is involved, where C and/or
    Z has given permission to S to decrypt? If so, that solves the
    riddle. But if S can routinely decrypt, then it's a mystery.

    RL

  12. #32
    unruh
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On 2010-11-03, RayLopez99 <raylopez88@gmail.com> wrote:
    > On Nov 2, 12:03?pm, unruh <un...@wormhole.physics.ubc.ca> wrote:
    >
    >>
    >> Your system contacts Z and asks for a public key. It then checks the
    >> signing authority of that public key against the set of signing
    >> authorities it has in its list. If it checks out, it then uses Z's
    >> public key to encrypt a random symmentric key, and encrypts the message with
    >> that symmetric key, and sends the encrypted symmetric key and the
    >> encrypted message out.
    >> Thus any S would need to know Z's private key, ?
    >>
    >> Now, if S could act as ?a man in the middle, and persuade ?your machine
    >> that S's public key is really Z's public key, then of course S could
    >> read your transmission. That is prevented by the "web of trust" -- the
    >> fact that you trust the signing authority who stated that Z's key really
    >> was Z's key. Of course if you do not have the signing authority's public
    >> key in your system or S has persuaded you (or your distro) to put a bogus public key for
    >> that signing authority into your system, the game is up.>O
    >>
    >> So no, without a lot of work, intermediate machines cannot read your SSL
    >> stuff sent to Z, or you ignored the warning from your browser that it
    >> did not know the signing authority for the key you are using.
    >>

    >
    > Unruh--you are probably late to this thread. The issue here is not
    > spoofing so much as the statement by others in this thread that S (the
    > intermediary) *CAN* read your SSL stuff. How it does this is the
    > question.


    The statements are wrong.

    >
    > One proposal (and I have yet to see this explicitly): for SSL
    > encrypted message routing to work, when involving intermediaries like
    > SOAP servers (like S in our A to S to Z transmission of a SSL
    > message), S the intermediary *must* be able to decrypt the message.


    Nonesense. It just passes it on.

    > It contacts the relevant endpoint, Z, gets permission to decrypt, and
    > does decrypt. Then it routes the message using the headers


    That would be a HUGE HUGE hole in SSL protocol. It might as well not
    exist if that were true.

    > (unencrypted). Before it transmits the message, S will of course


    The headers are ALWAYS unencrypted. That is how the message gets from A
    to B.

    > encrypt it again, so while the message is in transit nobody can read
    > it. But S itself can (and must) read the message for the transmission
    > to work.


    Bunnybeads.

    >
    > Can anybody confirm this? I've not seen this on the net, but it's a
    > logical inference from what I have seen.
    >
    > RL


  13. #33
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Oct 29, 8:36*pm, "FromTheRafters" <erra...@nomail.afraid.org>
    wrote:

    > ***
    > Yep, I learned that you are a stupid troll.
    >
    > Bye-bye
    > ***


    Here's
    a reference for you to 'bone up' on, bonehead: (http://
    msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx “End-to-end
    security. A secure transport, such as Secure Sockets Layer (SSL)
    works
    only when the communication is point-to-point. If the message is
    routed to one or more SOAP intermediaries before reaching the
    ultimate
    receiver, the message itself is not protected once an intermediary
    reads it from the wire. "

    EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
    PRESENT, DOPE.

    Ball is in your court. Cowardice and evasion noted.

    RL

  14. #34
    unruh
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On 2010-11-07, RayLopez99 <raylopez88@gmail.com> wrote:
    > On Oct 29, 8:36?pm, "FromTheRafters" <erra...@nomail.afraid.org>
    > wrote:
    >
    >> ***
    >> Yep, I learned that you are a stupid troll.
    >>
    >> Bye-bye
    >> ***

    >
    > Here's
    > a reference for you to 'bone up' on, bonehead: (http://
    > msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx ?End-to-end
    > security. A secure transport, such as Secure Sockets Layer (SSL)
    > works
    > only when the communication is point-to-point. If the message is
    > routed to one or more SOAP intermediaries before reaching the
    > ultimate
    > receiver, the message itself is not protected once an intermediary
    > reads it from the wire. "
    >
    > EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
    > PRESENT, DOPE.
    >
    > Ball is in your court. Cowardice and evasion noted.


    YOu are making the assumption that all people at microsoft.com know what
    they are talking about. That assumption need not be a good one. That is
    another possibility you seem to be avoiding.
    Also, a SOAP is a machine which is supposed to make changes to a
    document. In order to do so, it MUST be able toread and change the
    document. Thus if you are using ssl, the link must be from the original
    machine to the intermediary which must be able to decrypt the message.
    THe original must therefor sent the message to the SAOP intermiary
    encrypted with the intermediary's public key protocol.

    That is how I read it.


    >
    > RL


  15. #35
    FromTheRafters
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    "unruh" <unruh@wormhole.physics.ubc.ca> wrote in message
    news:slrnidducl.8ik.unruh@wormhole.physics.ubc.ca...
    > On 2010-11-07, RayLopez99 <raylopez88@gmail.com> wrote:
    >> On Oct 29, 8:36?pm, "FromTheRafters" <erra...@nomail.afraid.org>
    >> wrote:
    >>
    >>> ***
    >>> Yep, I learned that you are a stupid troll.
    >>>
    >>> Bye-bye
    >>> ***

    >>
    >> Here's
    >> a reference for you to 'bone up' on, bonehead: (http://
    >> msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx ?End-to-end
    >> security. A secure transport, such as Secure Sockets Layer (SSL)
    >> works
    >> only when the communication is point-to-point. If the message is
    >> routed to one or more SOAP intermediaries before reaching the
    >> ultimate
    >> receiver, the message itself is not protected once an intermediary
    >> reads it from the wire. "
    >>
    >> EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
    >> PRESENT, DOPE.
    >>
    >> Ball is in your court. Cowardice and evasion noted.

    >
    > YOu are making the assumption that all people at microsoft.com know
    > what
    > they are talking about. That assumption need not be a good one. That
    > is
    > another possibility you seem to be avoiding.
    > Also, a SOAP is a machine which is supposed to make changes to a
    > document. In order to do so, it MUST be able toread and change the
    > document. Thus if you are using ssl, the link must be from the
    > original
    > machine to the intermediary which must be able to decrypt the message.
    > THe original must therefor sent the message to the SAOP intermiary
    > encrypted with the intermediary's public key protocol.
    >
    > That is how I read it.


    Yes, Transport Layer Security is like the two cans and a string in a
    point-to-point communications link. You want to protect from anyone
    tapping the string getting your data while still having the users
    understand one another. It is about the *string* not about the cans
    (diaphrams) or the ears. In this analogy, the TLS would sit between the
    diaphrams and the strings and be transparent to the users. It is not
    about what the users can and cannot do, it is about what someone tapping
    the string would be able to do (nothing, because it is still encrypted
    at that point).

    If you want to keep your data secure from the people that you have
    trusted with the session keys, you should encrypt the data itself before
    sending it to the TLS.

    I won't be responding to any further posts by this troll until he learns
    not to crosspost. :o)

    Though I am pleasantly surprised he included the security group this
    time, he usually tries to pick groups where he has a chance to look
    superior on a given subject even though he obviously lacks clue.




  16. #36
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 7, 9:10*pm, unruh <un...@wormhole.physics.ubc.ca> wrote:

    >
    > YOu are making the assumption that all people at microsoft.com know what
    > they are talking about. That assumption need not be a good one. That is
    > another possibility you seem to be avoiding.


    Good point. The passage is unclear--it implies that the SOAP
    intermediary is an 'exception' to https being secure, akin to a Cross-
    site scripting (XSS) attack. But in fact, if your interpretation is
    correct, it's not really an exception.

    > Also, a SOAP is a machine which is supposed to make changes to a
    > document. In order to do so, it MUST be able toread and change the
    > document. Thus if you are using ssl, the link must be from the original
    > machine to the intermediary which must be able to decrypt the message.
    > THe original must therefor sent the message to the SAOP intermiary
    > encrypted with the intermediary's public key protocol.
    >
    > That is how I read it.


    Very logical, and it works to explain the passage, except for the fact
    it makes the passage trivial. If all Microsoft is saying (and not
    just Microsoft--I've seen similar language in a book on WCF by
    Resnick, an authority on WCF) is that 'when you send an SSL / TLS
    secured message to a SOAP intermediary, since SSL / TLS is only good
    for transport and not for the endpoints, don't forget that you must
    decrypt the message at the SOAP intermediary', well, this is very
    true, but trivial. How is that an exception to https being secure?
    An exception like XSS attacks? I think there might be more going on
    that nobody in this thread is aware of, but for the time being I guess
    we have to settle for your answer.

    Thanks for the reply.

    RL

  17. #37
    RayLopez99
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Nov 8, 12:56*am, "FromTheRafters" <erra...@nomail.afraid.org>
    wrote:
    >
    > Yes, Transport Layer Security is like the two cans and a string in a
    > point-to-point communications link. You want to protect from anyone
    > tapping the string getting your data while still having the users
    > understand one another. It is about the *string* not about the cans
    > (diaphrams) or the ears. In this analogy, the TLS would sit between the
    > diaphrams and the strings and be transparent to the users. It is not
    > about what the users can and cannot do, it is about what someone tapping
    > the string would be able to do (nothing, because it is still encrypted
    > at that point).
    >
    > If you want to keep your data secure from the people that you have
    > trusted with the session keys, you should encrypt the data itself before
    > sending it to the TLS.


    That last part makes no sense, kind of like you in real life.

    If you trust somebody with session keys, why would you want to keep
    your data secure from them? Again, see my reply just now to unruh.

    Either the passage is trivial (unruh's interpretation, and for now I
    have to agree with him), or, there's more going on that none of us is
    aware of. That's also a possibility, as I've seen this language in a
    textbook. Unless the textbook author was merely parroting the unclear
    language from Microsoft, which I guess is possible too.

    RL

  18. #38
    Ari Silverstein
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Sun, 7 Nov 2010 15:44:43 -0800 (PST), RayLopez99 wrote:

    > Either the passage is trivial (unruh's interpretation, and for now I
    > have to agree with him), or, there's more going on that none of us is
    > aware of.


    Yeah, you're unaware, that's for ****ing sure. lol
    --
    Talk about F-Cars - www.ferrarichat.com/forum/member.php?u=89702

  19. #39
    FromTheRafters
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    "unruh" <unruh@wormhole.physics.ubc.ca> wrote in message
    news:slrnidducl.8ik.unruh@wormhole.physics.ubc.ca...
    > On 2010-11-07, RayLopez99 <raylopez88@gmail.com> wrote:
    >> On Oct 29, 8:36?pm, "FromTheRafters" <erra...@nomail.afraid.org>
    >> wrote:
    >>
    >>> ***
    >>> Yep, I learned that you are a stupid troll.
    >>>
    >>> Bye-bye
    >>> ***

    >>
    >> Here's
    >> a reference for you to 'bone up' on, bonehead: (http://
    >> msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx ?End-to-end
    >> security. A secure transport, such as Secure Sockets Layer (SSL)
    >> works
    >> only when the communication is point-to-point. If the message is
    >> routed to one or more SOAP intermediaries before reaching the
    >> ultimate
    >> receiver, the message itself is not protected once an intermediary
    >> reads it from the wire. "
    >>
    >> EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
    >> PRESENT, DOPE.
    >>
    >> Ball is in your court. Cowardice and evasion noted.

    >
    > YOu are making the assumption that all people at microsoft.com know what
    > they are talking about. That assumption need not be a good one. That is
    > another possibility you seem to be avoiding.


    They seemed to me to be trying to make the point that it is the *session*
    that is encrypted and how that subtle difference is manifested when someone
    tries to implement *it* instead of using file encryption (end-to-end as
    opposed to point-to-point).



  20. #40
    Registered User
    Guest

    Re: Anybody know how https *really* works? I didn't think so

    On Sun, 7 Nov 2010 15:44:43 -0800 (PST), RayLopez99
    <raylopez88@gmail.com> wrote:

    >On Nov 8, 12:56*am, "FromTheRafters" <erra...@nomail.afraid.org>
    >wrote:
    >>
    >> Yes, Transport Layer Security is like the two cans and a string in a
    >> point-to-point communications link. You want to protect from anyone
    >> tapping the string getting your data while still having the users
    >> understand one another. It is about the *string* not about the cans
    >> (diaphrams) or the ears. In this analogy, the TLS would sit between the
    >> diaphrams and the strings and be transparent to the users. It is not
    >> about what the users can and cannot do, it is about what someone tapping
    >> the string would be able to do (nothing, because it is still encrypted
    >> at that point).
    >>
    >> If you want to keep your data secure from the people that you have
    >> trusted with the session keys, you should encrypt the data itself before
    >> sending it to the TLS.

    >
    >That last part makes no sense, kind of like you in real life.
    >

    It makes absolute sense! Intermediate tiers need to decrypt the
    envelope. If the letter does not have additional encryption its
    contents will be decrypted when the envelope is encrypted.

    If the letter is encrypted before it goes in the envelope, the letter
    will remain encrypted when an intermediate tier decrypts the envelope.

    >If you trust somebody with session keys, why would you want to keep
    >your data secure from them? Again, see my reply just now to unruh.
    >

    You are confusing authentication and authorization. Reading about
    roles and memberships may provide some insights.

    >Either the passage is trivial (unruh's interpretation, and for now I
    >have to agree with him), or, there's more going on that none of us is
    >aware of. That's also a possibility, as I've seen this language in a
    >textbook. Unless the textbook author was merely parroting the unclear
    >language from Microsoft, which I guess is possible too.
    >


    The problem is something doesn't work the way you expect. This has
    occurred before.

    regards
    A.G.

Similar Threads

  1. My trackball explorer works now? Why?
    By Chrome_ in forum Hardware & Overclocking
    Replies: 1
    Last Post: 04-27-10, 08:04 AM
  2. Stress reliever -and it really works.....
    By blacklab in forum General Discussion Board
    Replies: 5
    Last Post: 02-19-09, 05:25 PM
  3. Https connections fail after June Security updates (BlueTooth Patc
    By =?Utf-8?B?U2VjdXJpdHlHaXJs?= in forum ms.public.windows.networking.wireless
    Replies: 0
    Last Post: 06-24-08, 02:50 AM
  4. 2 works 1 not! (Home Networking)
    By BilalKhan in forum Networking Forum
    Replies: 4
    Last Post: 12-24-07, 02:56 AM
  5. How to make 2 lan works together???
    By bohosh in forum Wireless Networks & Routers
    Replies: 6
    Last Post: 02-27-07, 09:46 AM

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
  •