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

So my book on https and Windows Communication Foundation technology
says that if any computer between your SSL certificate secured
computer and the client machine reading this certificate does not
support SSL, then the entire https link is not secure and your data
can be compromised. That makes no sense to me, because I thought the
entire data stream is encrypted, but that's what it says. And I've
even seen this on the net.

So why do people blindly trust SSL and HTTPS as if it's unbreakable?
Is it because most traffic goes through at most two or three hops, and
likely these hops are up-to-date and support SSL?

Even if so, you're taking a risk that somewhere between somebody will
fail to support SSL and your message will be unencrypted.

Bet most if not all of you reading this thread did not know this. So
called experts, right.

RL

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

"RayLopez99" <raylopez88@gmail.com> wrote in message
news:3b8ac230-21fa-4b5f-8758-3ed63416f172@j18g2000yqd.googlegroups.com...
> So my book on https and Windows Communication Foundation technology
> says that if any computer between your SSL certificate secured
> computer and the client machine reading this certificate does not
> support SSL, then the entire https link is not secure and your data
> can be compromised. That makes no sense to me, because I thought the
> entire data stream is encrypted, but that's what it says. And I've
> even seen this on the net.

Encryption is only as secure as the key management system is.

> So why do people blindly trust SSL and HTTPS as if it's unbreakable?

Because they don't understand security as it pertains to encryption (or
vice versa).

> Is it because most traffic goes through at most two or three hops, and
> likely these hops are up-to-date and support SSL?

???

> Even if so, you're taking a risk that somewhere between somebody will
> fail to support SSL and your message will be unencrypted.

It just unencrypts, like that?

....I don't think so.

> Bet most if not all of you reading this thread did not know this. So
> called experts, right.

I don't think that you really fully understand what you are talking
about, so it seems ironic when you lamely attempt to insult and troll
those you somehow believe to be *experts* in so many disparate
crossposted groups.

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

On Oct 28, 5:47*pm, RayLopez99 <raylope...@gmail.com> wrote:
> So my book on https and Windows Communication Foundation technology
> says that if any computer between your SSL certificate secured
> computer and the client machine reading this certificate does not
> support SSL, then the entire https link is not secure and your data
> can be compromised. *That makes no sense to me, because I thought the
> entire data stream is encrypted, but that's what it says. *And I've
> even seen this on the net.
>
> So why do people blindly trust SSL and HTTPS as if it's unbreakable?
> Is it because most traffic goes through at most two or three hops, and
> likely these hops are up-to-date and support SSL?
>
> Even if so, you're taking a risk that somewhere between somebody will
> fail to support SSL and your message will be unencrypted.
>
> Bet most if not all of you reading this thread did not know this. *So
> called experts, right.
>
> RL

Your profile suggests that you work in the agricultural industry. If
those who work in the agricultural industry knew that you're giving
them a bad name, I'm sure they wouldn't hesitate to toss you into the
corn feeder a second time.

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

On Oct 29, 3:44*am, "FromTheRafters" <erra...@nomail.afraid.org>
wrote:
> "RayLopez99" <raylope...@gmail.com> wrote in message
>
> news:3b8ac230-21fa-4b5f-8758-3ed63416f172@j18g2000yqd.googlegroups.com...
>
> > So my book on https and Windows Communication Foundation technology
> > says that if any computer between your SSL certificate secured
> > computer and the client machine reading this certificate does not
> > support SSL, then the entire https link is not secure and your data
> > can be compromised. *That makes no sense to me, because I thought the
> > entire data stream is encrypted, but that's what it says. *And I've
> > even seen this on the net.
>
> Encryption is only as secure as the key management system is.

Nope, Shiite->4Brains, that' s NOT what we are talking about. Try
again. We are talking about HTTPS, not key management. Yes, it's
true that key management is only as secure as the lock on your door to
the secondary storage holding said keys, but again, that's not at
issue here.

>
> > So why do people blindly trust SSL and HTTPS as if it's unbreakable?
>
> Because they don't understand security as it pertains to encryption (or
> vice versa).
>
> > Is it because most traffic goes through at most two or three hops, and
> > likely these hops are up-to-date and support SSL?
>
> ???

Right. ???. That's your value add to this debate: ???. That should
be your middle name: ??? The Reflex.

>
> > Even if so, you're taking a risk that somewhere between somebody will
> > fail to support SSL and your message will be unencrypted.
>
> It just unencrypts, like that?

Yes, just like that. What you fail to understand (among your many
other failures) is the difference between message level security and
transport level security. HTTPS is the latter not the former. 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. Additionally, the client authentication
information is available only to the first intermediary and must be
transmitted to the ultimate received in out-of-band fashion, if
necessary. This applies even if the entire route uses SSL security
between individual hops. Because message security works directly with
the message and secures the XML in it, the security stays with the
message regardless of how many intermediaries are involved with the
message before it reaches the ultimate receiver. This enables true end-
to-end security scenario.”)

>
> ...I don't think so.
>

You *STILL* don't think so, even after reading the above? Man youz
stupid.

> > Bet most if not all of you reading this thread did not know this. *So
> > called experts, right.
>
> I don't think that you really fully understand what you are talking
> about, so it seems ironic when you lamely attempt to insult and troll
> those you somehow believe to be *experts* in so many disparate
> crossposted groups.

NOT. I hope you lerned something from this thread, dopehead.

Anybody else? C'mon down! Insults are free of charge.

RL

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

On Oct 29, 1:32*pm, RayLopez99 <raylope...@gmail.com> wrote:

>
> Yes, just like that. *What you fail to understand (among your many
> other failures) is the difference between message level security and
> transport level security. *HTTPS is the latter not the former. *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. Additionally, the client authentication
> information is available only to the first intermediary and must be
> transmitted to the ultimate received in out-of-band fashion, if
> necessary. This applies even if the entire route uses SSL security
> between individual hops. Because message security works directly with
> the message and secures the XML in it, the security stays with the
> message regardless of how many intermediaries are involved with the
> message before it reaches the ultimate receiver. This enables true end-
> to-end security scenario.”)
>

The only thing left to debate--and I doubt the small minds in this
group has the capacity to address this issue (no thanks in advance)--
is how often "SOAP intermediaries" are present in a 'typical' message
route. I would bet that for most 'routine' messages such as home user
to bank server, there would be no intermediaries, and the ISP server
is just "pass through" and would not require SOAP (I would imagine).
But this is a question for a real expert, not the dunces that hang
around the virtual water cooler that passes for Usenet these days.

RL

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

"RayLopez99" <raylopez88@gmail.com> wrote in message
news:a19c2475-597a-4a95-a492-cc9038ceeb09@l17g2000yqe.googlegroups.com...
On Oct 29, 3:44 am, "FromTheRafters" <erra...@nomail.afraid.org>
wrote:
> "RayLopez99" <raylope...@gmail.com> wrote in message
>
> news:3b8ac230-21fa-4b5f-8758-3ed63416f172@j18g2000yqd.googlegroups.com...
>
> > So my book on https and Windows Communication Foundation technology
> > says that if any computer between your SSL certificate secured
> > computer and the client machine reading this certificate does not
> > support SSL, then the entire https link is not secure and your data
> > can be compromised. That makes no sense to me, because I thought the
> > entire data stream is encrypted, but that's what it says. And I've
> > even seen this on the net.
>
> Encryption is only as secure as the key management system is.

Nope, Shiite->4Brains, that' s NOT what we are talking about.

***
So it just magically unencrypts itself?
***

Try again. We are talking about HTTPS, not key management. Yes, it's
true that key management is only as secure as the lock on your door to
the secondary storage holding said keys, but again, that's not at
issue here.

***
So it just magically unencrypts itself?
***

> > So why do people blindly trust SSL and HTTPS as if it's unbreakable?
>
> Because they don't understand security as it pertains to encryption
> (or
> vice versa).
>
> > Is it because most traffic goes through at most two or three hops,
> > and
> > likely these hops are up-to-date and support SSL?
>
> ???

Right. ???. That's your value add to this debate: ???. That should
be your middle name: ??? The Reflex.

***
That was an indication that I didn't understand what you were talking
about, but I see now what that was so.
***

> > Even if so, you're taking a risk that somewhere between somebody
> > will
> > fail to support SSL and your message will be unencrypted.
>
> It just unencrypts, like that?

Yes, just like that. What you fail to understand (among your many
other failures) is the difference between message level security and
transport level security. HTTPS is the latter not the former.

***
Why the animosity? Can you explain how something can encrypt at one end,
and decrypt at the other, without some kind of key being involved?
***

[...]

> ...I don't think so.

You *STILL* don't think so, even after reading the above? Man youz
stupid.

***
Not really, it's just that you not only fail to make sense, you fail to
understand the subject enough to explain to me what you actually meant.

....and you're still acting like an asshole toward me for no good reason
(aside from the obvious trolling that is).
***

> > Bet most if not all of you reading this thread did not know this. So
> > called experts, right.
>
> I don't think that you really fully understand what you are talking
> about, so it seems ironic when you lamely attempt to insult and troll
> those you somehow believe to be *experts* in so many disparate
> crossposted groups.

NOT. I hope you lerned something from this thread, dopehead.

***
Yep, I learned that you are a stupid troll.

Bye-bye
***

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

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

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

Nope. You fail to understand how transport security works. The one
passage that was not flamebait you clipped (and I reproduce it again,
below).

So, where you trolling then? You clearly have no interest in lerning
anything from this thread, trollfeeder.

And I don't know why SOAP intermediaries break https. That really was
my question to the group.

Bye.

RL

(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. Additionally, the client authentication
information is available only to the first intermediary and must be
transmitted to the ultimate received in out-of-band fashion, if
necessary. This applies even if the entire route uses SSL security
between individual hops. Because message security works directly with
the message and secures the XML in it, the security stays with the
message regardless of how many intermediaries are involved with the
message before it reaches the ultimate receiver. This enables true
end-
to-end security scenario.”)

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

RayLopez99 wrote:
>
> And I don't know why SOAP intermediaries break https. That really was
> my question to the group.
>

Perhaps Microsoft didn't explain it well enough for you.

Design 1. C (client) -- internet -- Z (destination server)

If your client uses HTTPS and the URL of Z, then your message is safe.

Design 2. C -- internet -- S (intermediary) -- internet -- Z

If your client uses the URL of S, then S uses the URL of Z (even if
they're both using HTTPS) then your message may be read/altered by S.

What was not said is that in design 2, S should really be considered C's
destination, and Z is S's destination - and that protocol encryption
(HTTPS) only protects your message on its path through the internet.

If you don't want S to be able to read/alter your message then encrypt
the message so that only Z can read it - or use design 1 and HTTPS.

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

On Thu, 28 Oct 2010 15:47:35 -0700 (PDT), RayLopez99 wrote:

> So my book

What book?

> on https and Windows Communication Foundation technology
> says that if any computer between your SSL certificate secured
> computer and the client machine reading this certificate does not
> support SSL, then the entire https link is not secure and your data
> can be compromised. That makes no sense to me, because I thought the
> entire data stream is encrypted, but that's what it says. And I've
> even seen this on the net.

Where?

> So why do people blindly trust SSL and HTTPS as if it's unbreakable?
> Is it because most traffic goes through at most two or three hops, and
> likely these hops are up-to-date and support SSL?
>
> Even if so, you're taking a risk that somewhere between somebody will
> fail to support SSL and your message will be unencrypted.
>
> Bet most if not all of you reading this thread did not know this. So
> called experts, right.

*roflmao*

--
"The Toast of Buffalo! = http://tinyurl.com/2v9sjf9
Ari himself, with his unerring sense of what is hip, contributed a box
of doughnuts
from Famous Doughnuts, a company he owns."

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

On Oct 30, 4:19*am, Jason Keats <jke...@melbpcDeleteThis.org.au>
wrote:
> RayLopez99 wrote:
>
> > And I don't know why SOAP intermediaries break https. *That really was
> > my question to the group.
>
> Perhaps Microsoft didn't explain it well enough for you.

Neither did you Jason, but I appreciate the attempt. Please read on
however.

>
> Design 1. C (client) -- internet -- Z (destination server)
>
> If your client uses HTTPS and the URL of Z, then your message is safe.
>
> Design 2. C -- internet -- S (intermediary) -- internet -- Z
>
> If your client uses the URL of S, then S uses the URL of Z (even if
> they're both using HTTPS) then your message may be read/altered by S.

What are you saying here? Are you saying that S has the ability to
"alter" your message, by say garbling it? To make it unreadable?
(That is, change every letter Y to X and Z character to A, etc? That
would be simple vandalism, and not really a security 'breach' in my
mind. Or are you saying that S has a private key to the HTTPS and can
unencrypt your encrypted message? That was what I thought originally--
and it's still not clear how S can get a private key--only "Z" has
such a key (that's my understanding). I thought HTTPS uses some form
of asymmetric public key (I trust you know what this is), and that the
only holder of the private key is Z. But if HTTPS uses a symmetric
key, then I can see how S can indeed decrypt the message from C and
read it. Please explain. That's the last time I use "please" in
this thread BTW.

>
> What was not said is that in design 2, S should really be considered C's
> destination, and Z is S's destination - and that protocol encryption
> (HTTPS) only protects your message on its path through the internet.

Again, that is how I thought things work: using a asymmetric key,
that's exactly how things should work: every two points in a chain of
transmission is as strong as the next two points--there are no weak
links.

>
> If you don't want S to be able to read/alter your message then encrypt
> the message so that only Z {YES, THIS IS MESSAGE SECURITY, I AGREE} can read it - or use design 1 and HTTPS {I DON'T SEE HOW}

RL