Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #17476 > unrolled thread

Ecommerce site - how?

Back to article view | Back to comp.lang.php

Contents

  Ecommerce site - how? bit-naughty@hotmail.com - 2017-06-25 05:42 -0700
    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-25 15:30 +0200
      Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-25 16:03 +0200
      Re: Ecommerce site - how? gordonb.y152t@burditt.org (Gordon Burditt) - 2017-06-26 05:43 -0500
        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 17:12 +0200
          Re: Ecommerce site - how? "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-06-26 17:54 +0200
            Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 19:40 +0200
              Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 21:42 +0200
                Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 23:14 +0200
                  Re: Ecommerce site - how? "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-06-27 00:28 +0200
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 10:48 +0200
                  Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 07:56 +0200
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 12:27 +0200
                      Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 19:15 +0200
                        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 22:01 +0200
                          Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-28 07:07 +0200
                  Re: Ecommerce site - how? Gordon Burditt <gordon@hammy.burditt.org> - 2017-06-30 17:08 -0500
          Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 18:29 +0200
            Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 19:17 +0200
              Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 13:34 -0400
                Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 20:11 +0200
                  Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 21:31 +0200
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 22:29 +0200
                      Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 07:19 +0200
                        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 11:24 +0200
                          Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 19:43 +0200
                            Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 23:09 +0200
                              Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-28 07:12 +0200
                            Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 21:10 -0400
                  Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 16:32 -0400
                    Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 10:30 +0200
                      Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 08:38 -0400
                        Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 17:47 +0200
                          Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 12:16 -0400
                            Re: Ecommerce site - how? gordonb.bytf1@burditt.org (Gordon Burditt) - 2017-06-29 18:16 -0500
                              Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-29 20:41 -0400
                                Re: Ecommerce site - how? gordonb.99a3p@burditt.org (Gordon Burditt) - 2017-06-29 23:39 -0500
                                  Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-30 07:28 -0400
                                    Re: Ecommerce site - how? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-06-30 13:48 +0000
                                    Re: Ecommerce site - how? gordonb.gcghn@burditt.org (Gordon Burditt) - 2017-06-30 16:15 -0500
                                      Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-30 22:35 -0400
                              Re: Ecommerce site - how? Richard Damon <Richard@Damon-Family.org> - 2017-06-29 23:46 -0400
          Re: Ecommerce site - how? gordonb.d2wed@burditt.org (Gordon Burditt) - 2017-06-29 17:32 -0500
    Re: Ecommerce site - how? bit-naughty@hotmail.com - 2017-06-27 10:58 -0700
      Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 15:34 -0400
      Re: Ecommerce site - how? gordonb.4psc7@burditt.org (Gordon Burditt) - 2017-06-30 16:55 -0500
        Re: Ecommerce site - how? bit-naughty@hotmail.com - 2017-07-01 03:03 -0700
          Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-01 09:30 -0400
          Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-01 09:34 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#17486

Jerry,

> The same thing can happen for anyone using a common router.

Nope.  And I'm not even going to explain that.

> It could even happen at my home where I have only one router
> because I have a dynamic address.  That address can change at
> any time and I don't track when the lease runs out.

You're absolutily right ofcourse, thats exactly why gamers cannot play their
online games for an extended period of time.  The newsgroups and fora are
full with people complaining about it !  /s

And for your information: Besides the fact that most leases are way longer
than most users have their puter on (eight days), a lease is normally simply
extended (with the same IP) by sending a lease renewal request (before the
old one expires ofcourse).

> It does NOT hold a connection open while you go to lunch
> while leaving your browser open.

They don't ?    Does that mean I can't go on a holliday and than just
continue shopping either ?    Who could have known ... /s

Regards,
Rudy Wieser


-- Origional mesage:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
oirgc3$hu4$1@jstuckle.eternal-september.org...
> On 6/26/2017 1:17 PM, R.Wieser wrote:
> > J.O.,
> >
> >> In Gordon's example it changes with each request, this could be
> >> a user using tor network to do their shopping
> >
> > While that is possible*, the problem is than knowingly created by the
> > user**, and not the website.   As such its upto the users (maybe
together
> > with the tor network maintainers) to find a solution for it.
> >
>
> The same thing can happen for anyone using a common router.  AOL users,
> for instance, can have this problem.  So can users at large companies
> who use multiple routers running in parallel between the users and the
> internet.
>
> It could even happen at my home where I have only one router because I
> have a dynamic address.  That address can change at any time and I don't
> track when the lease runs out.
>
> > *though the client (read: his webbrowser) can, and normaly does request
to
> > keep the HTTP connection open, so that it does not need to spend time on
> > setting up before and tearing down after each request + answer.
> >
>
> It only stays open long enough to complete the current request.  For
> instance, the browser requests a page.  In that page are images and
> links to other files such as css and javascript, which also need to be
> loaded to fully satisfy the request.  The browser keeps the connection
> open long enough to load all of these additional files, then closes the
> connection.  It does NOT hold a connection open while you go to lunch
> while leaving your browser open.
>
> > **I really do *not* want to know what kind of "shopping" you're doing
when
> > you think you need tor for to obsfucate it. :-)
> >
> > Regards,
> > Rudy Wieser
>
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

[toc] | [prev] | [next] | [standalone]

#17487

On 06/26/17 20:11, R.Wieser wrote:

>> The same thing can happen for anyone using a common router.
> Nope.  And I'm not even going to explain that.

Just for simplify things, your point is valid in most cases, but still
Jerry is as right too and as you said we will not go into details, so we
won't explain why Jerry is right.


>> It could even happen at my home where I have only one router
>> because I have a dynamic address.  That address can change at
>> any time and I don't track when the lease runs out.
> 
> And for your information: Besides the fact that most leases are way longer
> than most users have their puter on (eight days), a lease is normally simply
> extended (with the same IP) by sending a lease renewal request (before the
> old one expires ofcourse).

What about the case when it's time to renew your lease and you happen to
be shopping and your ISP decided it's time for you to switch to a less
busy network. Of course we ain't saying it will happen each time you
request for an lease extension, but it's a potential outcome each time
you request to extend you lease.

Also keep in mind that IP can also be spoofed in a number of ways, so
keeping track of the IP is no way a good method, it's better to use
request verification tokens.


PS. Stop that stupid bottom posting of the previous post, even a second
grade news reader like outlook can manage to keep track of threads.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17490

J.O. ,

> but still Jerry is as right too

You should have read the paragraph just below it, and you would have known
his was-and-is either bullshit or at least *very* far fetched.

Furthermore,  if you would have read my messages you would have noticed that
I responded to Christoph by mentioning that his PHP session setup was a bit
over-simplified, and why I thought so.

But hey, complain first, read later I guess. :-((

> What about the case when it's time to renew your lease and you
> happen to be shopping and your ISP decided it's time for you to
> switch to a less busy network.

Than you have a  problem with your ISP, and not the e-commerce site.

Don't be as stupid to expect such a site to solve all the quirks the
intermediate ISPs have (purposely, often in full disregard to their
customers needs) inserted in their networks.

> Also keep in mind that IP can also be spoofed in a number of ways,
> so keeping track of the IP is no way a good method, it's better to use
> request verification tokens.

Lol.   I could explain to you that CSRF attack and link hijacking defense
methods must-and-are rather different (the first is done within your
browser, the second definitily not), but as you are the one suggesting it yu
must have an idea how its applicable. So, be my guest and explain.

And a hint: *both* parts of that "token" are placed in the same HTTP
request.

> PS. Stop that stupid bottom posting of the previous post, even a
> second grade news reader like outlook can manage to keep track
> of threads.

You're an arrogant, short-sighted shit   Your here-and-now is not the only
thing thats important you know.   Just imagine someone searching the web for
a certain answer, and all he can find is the current  message.   For that
reason I keep a copy of the origional post to at the bottom of my reply.

And if you do not like it, you *could* just stop at the line where I mention
"-- origional message:".  Or is that too hard for you ?

Regards,
Rudy Wieser


-- Origional message:   <-- This is it, you can stop reading now.
J.O. Aho <user@example.net> schreef in berichtnieuws
erd5pbFhbolU1@mid.individual.net...
> On 06/26/17 20:11, R.Wieser wrote:
>
> >> The same thing can happen for anyone using a common router.
> > Nope.  And I'm not even going to explain that.
>
> Just for simplify things, your point is valid in most cases, but still
> Jerry is as right too and as you said we will not go into details, so we
> won't explain why Jerry is right.
>
>
> >> It could even happen at my home where I have only one router
> >> because I have a dynamic address.  That address can change at
> >> any time and I don't track when the lease runs out.
> >
> > And for your information: Besides the fact that most leases are way
longer
> > than most users have their puter on (eight days), a lease is normally
simply
> > extended (with the same IP) by sending a lease renewal request (before
the
> > old one expires ofcourse).
>
> What about the case when it's time to renew your lease and you happen to
> be shopping and your ISP decided it's time for you to switch to a less
> busy network. Of course we ain't saying it will happen each time you
> request for an lease extension, but it's a potential outcome each time
> you request to extend you lease.
>
> Also keep in mind that IP can also be spoofed in a number of ways, so
> keeping track of the IP is no way a good method, it's better to use
> request verification tokens.
>
>
> PS. Stop that stupid bottom posting of the previous post, even a second
> grade news reader like outlook can manage to keep track of threads.
>
>  file://Aho

[toc] | [prev] | [next] | [standalone]

#17493

On 06/26/17 22:29, R.Wieser wrote:

>> What about the case when it's time to renew your lease and you
>> happen to be shopping and your ISP decided it's time for you to
>> switch to a less busy network.
> 
> Than you have a  problem with your ISP, and not the e-commerce site.

No, it's not an issue with ISP, it's the e-commerce site which is the issue.

> Don't be as stupid to expect such a site to solve all the quirks the
> intermediate ISPs have (purposely, often in full disregard to their
> customers needs) inserted in their networks.

So you mean that ISP should provide the worse possible customer
experience so that badly designed e-commerce sites would keep on working?


>> Also keep in mind that IP can also be spoofed in a number of ways,
>> so keeping track of the IP is no way a good method, it's better to use
>> request verification tokens.
> 
> Lol.   I could explain to you that CSRF attack and link hijacking defense
> methods must-and-are rather different (the first is done within your
> browser, the second definitily not), but as you are the one suggesting it yu
> must have an idea how its applicable. So, be my guest and explain.
> 
> And a hint: *both* parts of that "token" are placed in the same HTTP
> request.

Yes, it will be part of the same http post, but that don't mean it will
be automatically added to CSRF request. So just make a second visit to
OWASP and start reading.


>> PS. Stop that stupid bottom posting of the previous post, even a
>> second grade news reader like outlook can manage to keep track
>> of threads.
> 
> You're an arrogant, short-sighted shit   Your here-and-now is not the only
> thing thats important you know.   Just imagine someone searching the web for
> a certain answer, and all he can find is the current  message.   For that
> reason I keep a copy of the origional post to at the bottom of my reply.

Yes, if he finds current one, he will find the previous one too, unless
using some obscure search engine that just index one message in each thread.

> And if you do not like it, you *could* just stop at the line where I mention

It's just extra work on your posts with deleting and by the way the your
news client modifies the "original" text.

[toc] | [prev] | [next] | [standalone]

#17498

J.O.

> No, it's not an issue with ISP, it's the e-commerce site which is the
issue.

Ofcourse it is !   I guess when your bike has a flat tire you will complain
to the brick-and-mortar store too ? /s

> So you mean that ISP should provide the worse possible customer
> experience so that badly designed e-commerce sites would keep on
> working?

One) Nope (who the heck said that ?   I'm rather sure I didn't).    But as
you are amadant that problems (knowingly!) created by your ISP (and others)
should be solved by whomever you want to connect to -- of which an
e-commerse site is just one, as I've been trying to explain a few times
now -- I don't think we have anything to discuss anymore.

Two) Its your ISP with its "lets change IPs whenever we like it"* who is the
one who is be causing the "worst possible customer experience", no matter
what site/server you connect to.   SSL connections will be dropped, logging
in will be broken for the same reason.

*something I do not even believe they do, as also explained.

> Yes, it will be part of the same http post, but that don't mean it will
> be automatically added to CSRF request.

The are part of the same http request, but not of the CSRF request ?   You
have to explain that one to me I'm afraid.  And no, I'm not going to scour
that site in search of what you might be thinking of.  Either you link to or
quote it, or I'm going to consider this matter closed (don't want to waste
more time at it as I've already done).

> Yes, if he finds current one, he will find the previous one too,

Nope.   And believe me, as thats my experience with searching the interwebs
speaking there.  Sometimes you can, but more often you don't.

> unless using some obscure search engine that just index one message in
each thread.

That must be it !  Now I understand.  Google is just one of those "obscure
search engine"s you're talking about ! /s

> It's just extra work on your posts with deleting and by the way the your
> news client modifies the "original" text.

Yes, it does.   It follows the RFC for NNTP messages, but does not attempt
any kind of reflow (as it doesn't make any presumtions about the "quote
chars" the different newsgroup clients might be using).  Blame MS for that.
:-)

But hey, what are you doing there ?   I *told* you you could stop at the
indicated line, but you ignored it and than still complain ?   You're really
a piece of work you know. :-D

Regards,
Rudy Wieser


-- Origional message:
J.O. Aho <user@example.net> schreef in berichtnieuws
ere866Fn9ftU1@mid.individual.net...
> On 06/26/17 22:29, R.Wieser wrote:
>
> >> What about the case when it's time to renew your lease and you
> >> happen to be shopping and your ISP decided it's time for you to
> >> switch to a less busy network.
> >
> > Than you have a  problem with your ISP, and not the e-commerce site.
>
> No, it's not an issue with ISP, it's the e-commerce site which is the
issue.
>
> > Don't be as stupid to expect such a site to solve all the quirks the
> > intermediate ISPs have (purposely, often in full disregard to their
> > customers needs) inserted in their networks.
>
> So you mean that ISP should provide the worse possible customer
> experience so that badly designed e-commerce sites would keep on working?
>
> >> Also keep in mind that IP can also be spoofed in a number of ways,
> >> so keeping track of the IP is no way a good method, it's better to use
> >> request verification tokens.
> >
> > Lol.   I could explain to you that CSRF attack and link hijacking
defense
> > methods must-and-are rather different (the first is done within your
> > browser, the second definitily not), but as you are the one suggesting
it yu
> > must have an idea how its applicable. So, be my guest and explain.
> >
> > And a hint: *both* parts of that "token" are placed in the same HTTP
> > request.
>
> Yes, it will be part of the same http post, but that don't mean it will
> be automatically added to CSRF request. So just make a second visit to
> OWASP and start reading.
>
>
> >> PS. Stop that stupid bottom posting of the previous post, even a
> >> second grade news reader like outlook can manage to keep track
> >> of threads.
> >
> > You're an arrogant, short-sighted shit   Your here-and-now is not the
only
> > thing thats important you know.   Just imagine someone searching the web
for
> > a certain answer, and all he can find is the current  message.   For
that
> > reason I keep a copy of the origional post to at the bottom of my reply.
>
> Yes, if he finds current one, he will find the previous one too, unless
> using some obscure search engine that just index one message in each
thread.
>
> > And if you do not like it, you *could* just stop at the line where I
mention
>
> It's just extra work on your posts with deleting and by the way the your
> news client modifies the "original" text.

[toc] | [prev] | [next] | [standalone]

#17503

On 06/27/17 11:24, R.Wieser wrote:
> J.O.
> 
>> No, it's not an issue with ISP, it's the e-commerce site which is the
> issue.
> 
> Ofcourse it is !   I guess when your bike has a flat tire you will complain
> to the brick-and-mortar store too ? /s

Depends on if the brick and mortar store has pored out glass shards on
the bike road or not.


>> So you mean that ISP should provide the worse possible customer
>> experience so that badly designed e-commerce sites would keep on
>> working?
> 
> One) Nope (who the heck said that ?   I'm rather sure I didn't).    But as
> you are amadant that problems (knowingly!) created by your ISP (and others)
> should be solved by whomever you want to connect to -- of which an
> e-commerse site is just one, as I've been trying to explain a few times
> now -- I don't think we have anything to discuss anymore.

So if IP-binding is so important protection, explain why non of the
major e-commerce, social media sites does it? Enlighten how you have
better knowledge than Amazon, eBay, ...


> Two) Its your ISP with its "lets change IPs whenever we like it"* who is the
> one who is be causing the "worst possible customer experience", no matter
> what site/server you connect to.   SSL connections will be dropped, logging
> in will be broken for the same reason.

I see you have no sense how things works, switching IP in the middle of
a session will not cause you any problems, unless you have someone
thinking IP-binding to session is the solution to everything.

Have you ever tried with a laptop, login into a site at home, then
hibernate it and go somewhere (maybe you have a friend you can visit)
and connect to the wifi, so your big surprise you will see that you are
still logged in. If you don't have a laptop, you can use your cell phone
first be on wifi and login, disable wifi and continue to surf.



>> Yes, it will be part of the same http post, but that don't mean it will
>> be automatically added to CSRF request.
> 
> The are part of the same http request, but not of the CSRF request ?   You
> have to explain that one to me I'm afraid.  And no, I'm not going to scour
> that site in search of what you might be thinking of.  Either you link to or
> quote it, or I'm going to consider this matter closed (don't want to waste
> more time at it as I've already done).

Cookies are automatically added to a request to a page which has a
cookie on your browser. Data that must be sent with a POST/GET/PUT do
not be added automatically to a request which a third party request
makes in your browser.

As the CSRF request will have your IP (as it's your browser executing
it), binding the session to the IP will not protect you.


>> Yes, if he finds current one, he will find the previous one too,
> 
> Nope.   And believe me, as thats my experience with searching the interwebs
> speaking there.  Sometimes you can, but more often you don't.

Stop using obscure search engines then.


-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17507

J.O.

> Depends on if the brick and mortar store has pored out glass
> shards on the bike road or not.

Oh, such a *good* comparision.  Yes, its the e-commerce site who makes your
ISP change the IP all the time, and who has instructed your company to
install two modems and alternate connections on them ofcourse.  /s

> So if IP-binding is so important protection, explain why non of the
> major e-commerce, social media sites does it?

Lol.   I don't believe at all you are in any way privy to how those sites
handle their connections, though you sure want to make me believe you do.
Sorry, didn't work.

Though thru a change that has been happening on the web the last year or so
the IP check by comparing them with one stored into a PHP session has become
rather moot.  Can you guess which change ?

And if you can, can you explain *how* it has become moot ?

> Have you ever tried with a laptop, login into a site at home, then
> hibernate it and go somewhere (maybe you have a friend you can
> visit) and connect to the wifi, so your big surprise you will see that
> you are still logged in.

Logged in to *what* exactly ?   Some social site (which does not actually
care that much who's on the connection), or on an e-commerce site (better
yet, a bank).  I higly doubt it that any of the latter two will allow you to
do that (if they would they would be, as far as I'm concerned, criminaly
stupid).

> you can use your cell phone first be on wifi and login, disable
> wifi and continue to surf.

:-) To you "it just works", doesn't it ?   You have absolutily no idea *how*
it does, but that doesn't stop you in the slightest in regard to trying to
use it as proof.

Look up handing off connections, and how it works.  And yes, that does need
the cooperation of either your ISP/phone company (assuming both
communication channels converge there), or the website you're connecting to.

> Cookies are automatically added to a request to a page which has
> a cookie on your browser.

True.

> Data that must be sent with a POST/GET/PUT do not be added
> automatically to a request which a third party request makes in
> your browser.

Care to rephrase that ?  Its rather unreadable to me.  It reads as some
legaleese mumbo-jumbo.  The words are there, just the sentence does not make
any sense. "data ... do not be added automatically to a request" ?   "a
request which a third party request makes" ?

As for "not be added automatically", what do you think is the chance that it
can be added "manually" ?  :-)

> As the CSRF request will have your IP (as it's your browser
> executing it), binding the session to the IP will not protect you.

Nope, and neither will any of the others method you can come up with, as a
well-written piece of malware will just change the data on the webpage
itself, just before the request gets actually send to the remote site*.
Your point is ?

*and yes, several strains of banking malware has been known to do exactly
that.

And no, we where, or at least I was, not talking about attacks from inside
the users computer.  If it has come that far than he's screwed anyway, one
way or the other.

> Stop using obscure search engines then.

You already said that.  Repeating it like this is either a sign of a feeble
mind, or of not really having anything to say to the reply you got the first
time you said it. What is it ?

Regards,
Rudy Wieser


-- Origional message:
J.O. Aho <user@example.net> schreef in berichtnieuws
erfjqtF14n4U1@mid.individual.net...
> On 06/27/17 11:24, R.Wieser wrote:
> > J.O.
> >
> >> No, it's not an issue with ISP, it's the e-commerce site which is the
> > issue.
> >
> > Ofcourse it is !   I guess when your bike has a flat tire you will
complain
> > to the brick-and-mortar store too ? /s
>
> Depends on if the brick and mortar store has pored out glass shards on
> the bike road or not.
>
> >> So you mean that ISP should provide the worse possible customer
> >> experience so that badly designed e-commerce sites would keep on
> >> working?
> >
> > One) Nope (who the heck said that ?   I'm rather sure I didn't).    But
as
> > you are amadant that problems (knowingly!) created by your ISP (and
others)
> > should be solved by whomever you want to connect to -- of which an
> > e-commerse site is just one, as I've been trying to explain a few times
> > now -- I don't think we have anything to discuss anymore.
>
> So if IP-binding is so important protection, explain why non of the
> major e-commerce, social media sites does it? Enlighten how you have
> better knowledge than Amazon, eBay, ...
>
> > Two) Its your ISP with its "lets change IPs whenever we like it"* who is
the
> > one who is be causing the "worst possible customer experience", no
matter
> > what site/server you connect to.   SSL connections will be dropped,
logging
> > in will be broken for the same reason.
>
> I see you have no sense how things works, switching IP in the middle of
> a session will not cause you any problems, unless you have someone
> thinking IP-binding to session is the solution to everything.
>
> Have you ever tried with a laptop, login into a site at home, then
> hibernate it and go somewhere (maybe you have a friend you can visit)
> and connect to the wifi, so your big surprise you will see that you are
> still logged in. If you don't have a laptop, you can use your cell phone
> first be on wifi and login, disable wifi and continue to surf.
>
> >> Yes, it will be part of the same http post, but that don't mean it will
> >> be automatically added to CSRF request.
> >
> > The are part of the same http request, but not of the CSRF request ?
You
> > have to explain that one to me I'm afraid.  And no, I'm not going to
scour
> > that site in search of what you might be thinking of.  Either you link
to or
> > quote it, or I'm going to consider this matter closed (don't want to
waste
> > more time at it as I've already done).
>
> Cookies are automatically added to a request to a page which has a
> cookie on your browser. Data that must be sent with a POST/GET/PUT do
> not be added automatically to a request which a third party request
> makes in your browser.
>
> As the CSRF request will have your IP (as it's your browser executing
> it), binding the session to the IP will not protect you.
>
> >> Yes, if he finds current one, he will find the previous one too,
> >
> > Nope.   And believe me, as thats my experience with searching the
interwebs
> > speaking there.  Sometimes you can, but more often you don't.
>
> Stop using obscure search engines then.
> --
>
>  file://Aho

[toc] | [prev] | [next] | [standalone]

#17510

On 06/27/17 23:09, R.Wieser wrote:
> J.O.
> 
>> Depends on if the brick and mortar store has pored out glass
>> shards on the bike road or not.
> 
> Oh, such a *good* comparision.  Yes, its the e-commerce site who makes your
> ISP change the IP all the time, and who has instructed your company to
> install two modems and alternate connections on them ofcourse.  /s

Yet again you prove that you have no concept on real world solutions,
but good you figure out yet another way your site would not work.

I'll follow Jerry's advice and stop feeding the Troll.

[toc] | [prev] | [next] | [standalone]

#17508

J.O.,

I suggest you give it up.  You are arguing with an idiot who thinks he
knows everything but knows absolutely nothing.  His comment about the
"interwebs" shows his level of competence.

He's never built an ecommerce site; I've built several (and working on
another one right now), and IIRC, you've built more than one, also.
Rudy has never built any ecommerce sites, but knows for sure how they work.

It reminds me of one of my mother's sayings.  "Never try to teach a pig
to sing.  It wastes your time and annoys the pig."

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17489

On 6/26/2017 2:11 PM, R.Wieser wrote:
> Jerry,
> 
>> The same thing can happen for anyone using a common router.
> 
> Nope.  And I'm not even going to explain that.
> 
>> It could even happen at my home where I have only one router
>> because I have a dynamic address.  That address can change at
>> any time and I don't track when the lease runs out.
> 
> You're absolutily right ofcourse, thats exactly why gamers cannot play their
> online games for an extended period of time.  The newsgroups and fora are
> full with people complaining about it !  /s
>

Which is NOT a problem with DHCP.

> And for your information: Besides the fact that most leases are way longer
> than most users have their puter on (eight days), a lease is normally simply
> extended (with the same IP) by sending a lease renewal request (before the
> old one expires ofcourse).
> 

It doesn't matter how long my *computer* is on.  What counts is how long
my *router* is on - which is 24/7/365.  My computer has a completely
different address on my LAN.  In fact, all of the computers, printers
and other networked peripherals have different IP addresses on the LAN -
but all share the same external IP address.

Whether a lease is extended or not is completely up to the DHCP server.
Most will just assign one from a group of free IP addresses.  And since
the one just released is at the top of the list, it will get reassigned.
 However, if there is a power failure and the system is out for an
extended period of time (we've been without power for as long as five
days), a new IP will most probably be reassigned.

>> It does NOT hold a connection open while you go to lunch
>> while leaving your browser open.
> 
> They don't ?    Does that mean I can't go on a holliday and than just
> continue shopping either ?    Who could have known ... /s
> 

Whether you can or not has absolutely nothing to do with whether the
connection is maintained or not.

> Regards,
> Rudy Wieser
> 
> 


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17495

Jerry,

> > You're absolutily right ofcourse, thats exactly why gamers cannot
> > play their online games for an extended period of time.  The
> > newsgroups and fora are full with people complaining about it !  /s
>
> Which is NOT a problem with DHCP.

:-) I know.  Thats what that "/s" (short for "end of sarcasm") is all about.

... and also the paragraph below (which describes lease renewal)

> It doesn't matter how long my *computer* is on.  What counts is
> how long my *router* is on - which is 24/7/365.

Nope.   Its your *modem* which is the deciding factor here (the one which
holds the wan IP, not some intermediate router).

But in the case you actually ment "modem" where you mentioned "router": It
can just send lease renewal messages, and all would be well -- you could
keep a fixed IP for as long as your modem doesn't loose its connection to
the ISP.

> Whether a lease is extended or not is completely up to the DHCP
> server. Most will just assign one from a group of free IP addresses.
>  And since the one just released is at the top of the list, it will get
reassigned.

Almost, but not quite.  Renewal does not mean you drop the IP you have and
do another "I do not have an IP, please give me one" request, it means that
you are requesting *an extension* of the one you already have (you are
sending your current IP as the one you would like to get).   Most DHCP
systems will honor it.

Ofcourse, as some ISPs do not really like you having a fixed IP for some or
another reason, several have introduced the "lets reset the connection
somewhere after midnight", meaning that your modems IP changes at that time,
even when it did not loose its connection.

Bottom line: I don't think that any of them will be daft enough to just
reset the connection when they feel like it, as it would create havoc for
*all* kinds of communications (including the already-mentioned gaming
sessions, but also phonecalls, movie/music stream, etc), especially SSL
connections (they would just be terminated). They would loose customers in
droves.

>  However, if there is a power failure and the system is out for an
> extended period of time (we've been without power for as long as
> five days), a new IP will most probably be reassigned.

Power-cycling the modem will most often cause the same result (in other
words (very) short disconnections often do the same (unless the ISP has some
kind of "lingering" implemented).

> > They don't ?    Does that mean I can't go on a holliday and than
> > just continue shopping either ?    Who could have known ... /s
>
> Whether you can or not has absolutely nothing to do with whether
> the connection is maintained or not.

One word: Whoosh! (it went over your head).

But yes, it has got *nothing* to do with the connection.  Which was exactly
what I tried to convey there (sarcasm and all that).

Regards,
Rudy Wieser


-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
oirqom$o6b$1@jstuckle.eternal-september.org...
> On 6/26/2017 2:11 PM, R.Wieser wrote:
> > Jerry,
> >
> >> The same thing can happen for anyone using a common router.
> >
> > Nope.  And I'm not even going to explain that.
> >
> >> It could even happen at my home where I have only one router
> >> because I have a dynamic address.  That address can change at
> >> any time and I don't track when the lease runs out.
> >
> > You're absolutily right ofcourse, thats exactly why gamers cannot play
their
> > online games for an extended period of time.  The newsgroups and fora
are
> > full with people complaining about it !  /s
> >
>
> Which is NOT a problem with DHCP.
>
> > And for your information: Besides the fact that most leases are way
longer
> > than most users have their puter on (eight days), a lease is normally
simply
> > extended (with the same IP) by sending a lease renewal request (before
the
> > old one expires ofcourse).
>
> It doesn't matter how long my *computer* is on.  What counts is how long
> my *router* is on - which is 24/7/365.  My computer has a completely
> different address on my LAN.  In fact, all of the computers, printers
> and other networked peripherals have different IP addresses on the LAN -
> but all share the same external IP address.
>
> Whether a lease is extended or not is completely up to the DHCP server.
> Most will just assign one from a group of free IP addresses.  And since
> the one just released is at the top of the list, it will get reassigned.
>  However, if there is a power failure and the system is out for an
> extended period of time (we've been without power for as long as five
> days), a new IP will most probably be reassigned.
>
> >> It does NOT hold a connection open while you go to lunch
> >> while leaving your browser open.
> >
> > They don't ?    Does that mean I can't go on a holliday and than just
> > continue shopping either ?    Who could have known ... /s
>
> Whether you can or not has absolutely nothing to do with whether the
> connection is maintained or not.
>
> > Regards,
> > Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17499

On 6/27/2017 4:30 AM, R.Wieser wrote:
> Jerry,
> 
>>> You're absolutily right ofcourse, thats exactly why gamers cannot
>>> play their online games for an extended period of time.  The
>>> newsgroups and fora are full with people complaining about it !  /s
>>
>> Which is NOT a problem with DHCP.
> 
> :-) I know.  Thats what that "/s" (short for "end of sarcasm") is all about.
> 
> ... and also the paragraph below (which describes lease renewal)
> 
>> It doesn't matter how long my *computer* is on.  What counts is
>> how long my *router* is on - which is 24/7/365.
> 
> Nope.   Its your *modem* which is the deciding factor here (the one which
> holds the wan IP, not some intermediate router).
>

Nope.  My modem has no ip address.  It just sits there between my ISP's
cable and my router.  It's my router that has an IP address.

> But in the case you actually ment "modem" where you mentioned "router": It
> can just send lease renewal messages, and all would be well -- you could
> keep a fixed IP for as long as your modem doesn't loose its connection to
> the ISP.
> 

I meant exactly what I said.  And there is nothing in the RFC's which
require a DHCP server to reissue the same IP address when the old lease
expires.

>> Whether a lease is extended or not is completely up to the DHCP
>> server. Most will just assign one from a group of free IP addresses.
>>  And since the one just released is at the top of the list, it will get
> reassigned.
> 
> Almost, but not quite.  Renewal does not mean you drop the IP you have and
> do another "I do not have an IP, please give me one" request, it means that
> you are requesting *an extension* of the one you already have (you are
> sending your current IP as the one you would like to get).   Most DHCP
> systems will honor it.
> 

That is *exactly* what it means.  You don't request an extension.  You
request an IP address.  Most DHCP servers will reissue the same one, but
there is no requirement they do so.

> Ofcourse, as some ISPs do not really like you having a fixed IP for some or
> another reason, several have introduced the "lets reset the connection
> somewhere after midnight", meaning that your modems IP changes at that time,
> even when it did not loose its connection.
> 

Or it can be reset at 2:13 in the afternoon or any other time of day.
There is one again no requirement that they reset your IP at any
specific time.

> Bottom line: I don't think that any of them will be daft enough to just
> reset the connection when they feel like it, as it would create havoc for
> *all* kinds of communications (including the already-mentioned gaming
> sessions, but also phonecalls, movie/music stream, etc), especially SSL
> connections (they would just be terminated). They would loose customers in
> droves.
> 

What you *think* is meaningless.  What *happens* is what counts.  And
that is completely up to the ISP.  For instance, I just checked my
router. My lease expires in 74 minutes (about 9:43 AM here).  I may or
may not get a new IP address at that time.  But it doesn't matter
because I don't have any incoming connections.

And no, it doesn't mean phone calls, movie/music stream, SSL
connections, etc. are terminated.  All of those are bi-directional
connections and a change in IP address means at most seven packets would
have to be resent to the new IP.

>>  However, if there is a power failure and the system is out for an
>> extended period of time (we've been without power for as long as
>> five days), a new IP will most probably be reassigned.
> 
> Power-cycling the modem will most often cause the same result (in other
> words (very) short disconnections often do the same (unless the ISP has some
> kind of "lingering" implemented).
> 

Again, maybe or maybe not.  I've had short power outages here and have
unplugged the router for short periods.  Each time the router rebooted
and requested a new IP address.  My ISP gave it the same IP back.

>>> They don't ?    Does that mean I can't go on a holliday and than
>>> just continue shopping either ?    Who could have known ... /s
>>
>> Whether you can or not has absolutely nothing to do with whether
>> the connection is maintained or not.
> 
> One word: Whoosh! (it went over your head).
> 
> But yes, it has got *nothing* to do with the connection.  Which was exactly
> what I tried to convey there (sarcasm and all that).
> 

Gee, I thought the /s meant end of stupidity.

> Regards,
> Rudy Wieser


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17500

Jerry,

> Nope.  My modem has no ip address.  It just sits there between my
> ISP's cable and my router.  It's my router that has an IP address.

Than you've got a very uncommon setup (my apologies for bluntly assuming you
where one of those people who doesn't know the difference between a modem
and a toaster :-\ :-) ).  It doesn't really change anything though.

> And there is nothing in the RFC's which require a DHCP server to
> reissue the same IP address when the old lease expires.

True.   And there isn't anything in there that says that it *must* return an
IP either.  Your point ?  Or are you just trying to be pedantic ?  That
doesn't gain you any points, quite the opposite actually.

> You don't request an extension.  You request an IP address.

I think its best to agree that we disagree here.

> You request an IP address.

Implicite, or explicite ?   Quite a difference.

> Most DHCP servers will reissue the same one, but there is no
> requirement they do so.

And thats *exactly* what I said directly above your (above quoted) reply to
it.  Bloody hell bub, don't you actually *read* to what you are responding
to ?   :-(

> Or it can be reset at 2:13 in the afternoon or any other time of day.
> There is one again no requirement that they reset your IP at any
> specific time.

Do you now expect me to *AGAIN* explain how that would *not* be in the ISPs
best interest ?    I don't think so.  You can go in circles all you like,
but I'm not going to humour you further in that regard.

> What you *think* is meaningless.  What *happens* is what counts.

You should listen a bit more to your own advice.

> My lease expires in 74 minutes (about 9:43 AM here).  I may or
> may not get a new IP address at that time.  But it doesn't matter
> because I don't have any incoming connections.

You're pathetic.  The old "im not using it, so its not a problem to me"
defense.

I'm rather sure that if I would ask you what would happen if you where
actually using that connection and you would be getting a different IP you
would pretty-much ignore me or show me some wiggeling that would be envied
by a snake. :-(

> Gee, I thought the /s meant end of stupidity.

Absolutily!  your stupidity, my sarcasm. :-D

Goodby.   Don't expect more responses.

Regards,
Rudy Wieser



-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
oitjc0$mqv$1@jstuckle.eternal-september.org...
> On 6/27/2017 4:30 AM, R.Wieser wrote:
> > Jerry,
> >
> >>> You're absolutily right ofcourse, thats exactly why gamers cannot
> >>> play their online games for an extended period of time.  The
> >>> newsgroups and fora are full with people complaining about it !  /s
> >>
> >> Which is NOT a problem with DHCP.
> >
> > :-) I know.  Thats what that "/s" (short for "end of sarcasm") is all
about.
> >
> > ... and also the paragraph below (which describes lease renewal)
> >
> >> It doesn't matter how long my *computer* is on.  What counts is
> >> how long my *router* is on - which is 24/7/365.
> >
> > Nope.   Its your *modem* which is the deciding factor here (the one
which
> > holds the wan IP, not some intermediate router).
>
> Nope.  My modem has no ip address.  It just sits there between my ISP's
> cable and my router.  It's my router that has an IP address.
>
> > But in the case you actually ment "modem" where you mentioned "router":
It
> > can just send lease renewal messages, and all would be well -- you could
> > keep a fixed IP for as long as your modem doesn't loose its connection
to
> > the ISP.
>
> I meant exactly what I said.  And there is nothing in the RFC's which
> require a DHCP server to reissue the same IP address when the old lease
> expires.
>
> >> Whether a lease is extended or not is completely up to the DHCP
> >> server. Most will just assign one from a group of free IP addresses.
> >>  And since the one just released is at the top of the list, it will get
> > reassigned.
> >
> > Almost, but not quite.  Renewal does not mean you drop the IP you have
and
> > do another "I do not have an IP, please give me one" request, it means
that
> > you are requesting *an extension* of the one you already have (you are
> > sending your current IP as the one you would like to get).   Most DHCP
> > systems will honor it.
>
> That is *exactly* what it means.  You don't request an extension.  You
> request an IP address.  Most DHCP servers will reissue the same one, but
> there is no requirement they do so.
>
> > Ofcourse, as some ISPs do not really like you having a fixed IP for some
or
> > another reason, several have introduced the "lets reset the connection
> > somewhere after midnight", meaning that your modems IP changes at that
time,
> > even when it did not loose its connection.
>
> Or it can be reset at 2:13 in the afternoon or any other time of day.
> There is one again no requirement that they reset your IP at any
> specific time.
>
> > Bottom line: I don't think that any of them will be daft enough to just
> > reset the connection when they feel like it, as it would create havoc
for
> > *all* kinds of communications (including the already-mentioned gaming
> > sessions, but also phonecalls, movie/music stream, etc), especially SSL
> > connections (they would just be terminated). They would loose customers
in
> > droves.
>
> What you *think* is meaningless.  What *happens* is what counts.  And
> that is completely up to the ISP.  For instance, I just checked my
> router. My lease expires in 74 minutes (about 9:43 AM here).  I may or
> may not get a new IP address at that time.  But it doesn't matter
> because I don't have any incoming connections.
>
> And no, it doesn't mean phone calls, movie/music stream, SSL
> connections, etc. are terminated.  All of those are bi-directional
> connections and a change in IP address means at most seven packets would
> have to be resent to the new IP.
>
> >>  However, if there is a power failure and the system is out for an
> >> extended period of time (we've been without power for as long as
> >> five days), a new IP will most probably be reassigned.
> >
> > Power-cycling the modem will most often cause the same result (in other
> > words (very) short disconnections often do the same (unless the ISP has
some
> > kind of "lingering" implemented).
>
> Again, maybe or maybe not.  I've had short power outages here and have
> unplugged the router for short periods.  Each time the router rebooted
> and requested a new IP address.  My ISP gave it the same IP back.
>
> >>> They don't ?    Does that mean I can't go on a holliday and than
> >>> just continue shopping either ?    Who could have known ... /s
> >>
> >> Whether you can or not has absolutely nothing to do with whether
> >> the connection is maintained or not.
> >
> > One word: Whoosh! (it went over your head).
> >
> > But yes, it has got *nothing* to do with the connection.  Which was
exactly
> > what I tried to convey there (sarcasm and all that).
> >
>
> Gee, I thought the /s meant end of stupidity.
>
> > Regards,
> > Rudy Wieser
>
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

[toc] | [prev] | [next] | [standalone]

#17501

On 6/27/2017 11:47 AM, R.Wieser wrote:
> Jerry,
> 
>> Nope.  My modem has no ip address.  It just sits there between my
>> ISP's cable and my router.  It's my router that has an IP address.
> 
> Than you've got a very uncommon setup (my apologies for bluntly assuming you
> where one of those people who doesn't know the difference between a modem
> and a toaster :-\ :-) ).  It doesn't really change anything though.
>

Nope.  It depends on what your ISP is using.  We have fiber, and an
ethernet cable coming out of the ISP's box.  It plugs into the back of
my router and the WAN address on the router is assigned by my ISP.  I
could use their router instead, but don't need to.

Before this, we had cable (another company).  The modem was exactly that
- just a small box which converted the cable analog signal to an
ethernet signal.

This isn't a whole lot different from the pre-broadband days when we had
modems hooked into the phone line.

Now some routers have built-in modems.  But the modem still does not
have an IP address.  It is strictly a MOulater-DEModulator.

>> And there is nothing in the RFC's which require a DHCP server to
>> reissue the same IP address when the old lease expires.
> 
> True.   And there isn't anything in there that says that it *must* return an
> IP either.  Your point ?  Or are you just trying to be pedantic ?  That
> doesn't gain you any points, quite the opposite actually.
> 

No, if there are none available it doesn't have to return an IP.  And
I'm not being pedantic.  I'm stating how things work.

>> You don't request an extension.  You request an IP address.
> 
> I think its best to agree that we disagree here.
> 

Just show me which of the RFCs support your position.

>> You request an IP address.
> 
> Implicite, or explicite ?   Quite a difference.
> 

A client cannot request a specific IP address.

>> Most DHCP servers will reissue the same one, but there is no
>> requirement they do so.
> 
> And thats *exactly* what I said directly above your (above quoted) reply to
> it.  Bloody hell bub, don't you actually *read* to what you are responding
> to ?   :-(
> 

No that is NOT what you said.  You said the DHCP server will always
return the same IP address.  That is not the case.

>> Or it can be reset at 2:13 in the afternoon or any other time of day.
>> There is one again no requirement that they reset your IP at any
>> specific time.
> 
> Do you now expect me to *AGAIN* explain how that would *not* be in the ISPs
> best interest ?    I don't think so.  You can go in circles all you like,
> but I'm not going to humour you further in that regard.
> 

What you *think* is meaningless.  What *happens* is what counts.

>> What you *think* is meaningless.  What *happens* is what counts.
> 
> You should listen a bit more to your own advice.
> 

I do.

>> My lease expires in 74 minutes (about 9:43 AM here).  I may or
>> may not get a new IP address at that time.  But it doesn't matter
>> because I don't have any incoming connections.
> 
> You're pathetic.  The old "im not using it, so its not a problem to me"
> defense.
> 

Nope.  It doesn't matter.  I was on a webinar when the lease expired.
Not even a blip in the webinar - completely transparent.

> I'm rather sure that if I would ask you what would happen if you where
> actually using that connection and you would be getting a different IP you
> would pretty-much ignore me or show me some wiggeling that would be envied
> by a snake. :-(
> 

Nope, because connections are bi-directional.  My client was
communicating with the webinar's server.  If the IP changed, the next
packet would have the new address and the server would respond to the
new address.  At most seven packets would have to be retried.


>> Gee, I thought the /s meant end of stupidity.
> 
> Absolutily!  your stupidity, my sarcasm. :-D
> 
> Goodby.   Don't expect more responses.
> 
> Regards,
> Rudy Wieser
> 

No, no sarcasm from you.  Simple stupidity, as you have repeatedly shown.

Let me know when you have the RFC's which say the client can request a
specific IP.  Or that that ISP has to reissue the same IP to the client.
 Or any of the other wild claims you have made.

I won't be holding my breath.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17512

> Nope, because connections are bi-directional.  My client was
> communicating with the webinar's server.  If the IP changed, the next
> packet would have the new address and the server would respond to the
  ^^^^^^
Do you mean "connection" here?

> new address.  At most seven packets would have to be retried.

A TCP connection is defined as a unique combination of 4 items:
	- The server IP address
	- The client IP address
	- The server port number
	- The client port number.

You can't change any of these and have the connection stay up.
(Although the ends might have different views of what these values
are, especially in the case of NAT gateways).

One way for your IP to change would be a configuration change
in the DHCP server, followed by a lease renewal.  My DHCP servers
seem to like renewing the IP a client already has, but if that
IP is removed from the acceptable IPs for this client, it will
change.

If my (client) IP address changed due to renewing with a different
address, how does the TCP connection survive?  I've always observed
that both ends of the connection are disconnected.  Eventually they
time out and go away, but this might take 45 seconds.

NNTP connections don't survive an IP change, largely because they
stay up for hours while you're reading USENET, unlike a web server
which is likely to load a page and disconnect, so connections last
a few seconds.

Now, if the IP change happens between TCP connections (so none are
up when the change is made, that's OK).  I'm not so sure that http
wouldn't have a persistent connection that would have to time out
(and probably show an error on the browser).

[toc] | [prev] | [next] | [standalone]

#17513

On 6/29/2017 7:16 PM, Gordon Burditt wrote:
>> Nope, because connections are bi-directional.  My client was
>> communicating with the webinar's server.  If the IP changed, the next
>> packet would have the new address and the server would respond to the
>   ^^^^^^
> Do you mean "connection" here?
>

No, I mean packet.

>> new address.  At most seven packets would have to be retried.
> 
> A TCP connection is defined as a unique combination of 4 items:
> 	- The server IP address
> 	- The client IP address
> 	- The server port number
> 	- The client port number.
> 
> You can't change any of these and have the connection stay up.
> (Although the ends might have different views of what these values
> are, especially in the case of NAT gateways).
> 

That's true.   But a connection is also etheral.  It comes and goes all
the time.  For instance, if you request a page from a web site, you will
get a connection.  But once your browser has retrieved the page and all
associated files (CSS, javascript, images, etc.), the connection is
close.  Another page request results in another connection.

> One way for your IP to change would be a configuration change
> in the DHCP server, followed by a lease renewal.  My DHCP servers
> seem to like renewing the IP a client already has, but if that
> IP is removed from the acceptable IPs for this client, it will
> change.
> 

Or just the expiration of your current lease and the request for a new
one.  There is nothing in the RFC's which requires an ISP to reissue the
same IP upon lease renewal.

> If my (client) IP address changed due to renewing with a different
> address, how does the TCP connection survive?  I've always observed
> that both ends of the connection are disconnected.  Eventually they
> time out and go away, but this might take 45 seconds.
> 

See above.

> NNTP connections don't survive an IP change, largely because they
> stay up for hours while you're reading USENET, unlike a web server
> which is likely to load a page and disconnect, so connections last
> a few seconds.
> 

Nope.  My connection to my usenet server is created when I request a
download of updates, and closes after that.  it is open for a few
seconds at most.

> Now, if the IP change happens between TCP connections (so none are
> up when the change is made, that's OK).  I'm not so sure that http
> wouldn't have a persistent connection that would have to time out
> (and probably show an error on the browser).
> 
> 

See above.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17515

> That's true.   But a connection is also etheral.  

I don't know what that word is, and neither does dictionary.com.
I suspect you mean "ephemeral".

> It comes and goes all
> the time.  

No, not all of them are and not all of them are supposed to be.
And it seems to take 45 seconds to decide that the connection
actually has gone away if it got disconnected by the IP change
before it gets closed.

SSH, telnet, ftp, and http for big files can all last a significant
amount of time (e.g. an hour) where an IP change is likely to
interrupt them, and they do *NOT* automatically restart.  And if
you cut one off in the middle by an IP change, it takes time for
either end to realize it.  


> For instance, if you request a page from a web site, you will
> get a connection.  But once your browser has retrieved the page and all
> associated files (CSS, javascript, images, etc.), the connection is
> close.  Another page request results in another connection.

Whether or not that is a "short" period of time depends a lot on
how big the files are.  And if the browser connection gets cut off,
it does *NOT* cleanly restart, there are long pauses and error
messages, usually requiring a page reload to make the page viewable.

What is a "webinar"?  I think it involves real-time streaming
interactive video.  To get anything meaningful out of it, a connection
needs to last way more than a few seconds.  Since it's interactive,
you can't download the whole thing in 2 seconds and spend 2 hours
watching it.  (The same applies to VOIP phone calls).


>> One way for your IP to change would be a configuration change
>> in the DHCP server, followed by a lease renewal.  My DHCP servers
>> seem to like renewing the IP a client already has, but if that
>> IP is removed from the acceptable IPs for this client, it will
>> change.
>> 
> 
> Or just the expiration of your current lease and the request for a new
> one.  There is nothing in the RFC's which requires an ISP to reissue the
> same IP upon lease renewal.

There do seem to be provisions in the RFCs which permit renewing the
same IP without ever releasing it:  DHCPREQUEST/DHCPACK done before
lease expiration rather than DHCPDISCOVER/DHCPOFFER.  No, the ISP is
not required to reissue the same IP on lease renewal, and I suspect the
server is required to NOT reissue the same IP should it no longer be
available (e.g. a configuration change removing the IP from the pool or
dedicating it to another system.  Or perhaps banning the renewing
system by MAC address, in which case it gets NO IP).  

*MY* DHCP servers seem to like renewing the IP a client already has
unless there's a reason not to.  I also don't see any setting to
make them not do that besides changing the configuration so the
client isn't eligible for the IP they now have; I wanted to try it
out once to see if a certain glitch was caused by lease renewal,
but apparently mine don't have that feature.  Do you know of any
DHCP servers that have documented features to force IP changes
periodically?

I don't know what yours do.


>> If my (client) IP address changed due to renewing with a different
>> address, how does the TCP connection survive?  I've always observed
>> that both ends of the connection are disconnected.  Eventually they
>> time out and go away, but this might take 45 seconds.
>> 
> 
> See above.

Your answer seems to be that short-duration connections, such as a
few seconds, can't be interrupted by an IP change, which is ludicrous.

>
>> NNTP connections don't survive an IP change, largely because they
>> stay up for hours while you're reading USENET, unlike a web server
>> which is likely to load a page and disconnect, so connections last
>> a few seconds.
>> 
> 
> Nope.  My connection to my usenet server is created when I request a
> download of updates, and closes after that.  it is open for a few
> seconds at most.

I find that difficult to believe, even assuming you've got a 10 gigabit
connection all the way between you and your news server and nobody 
else is using it.  I know you subscribe to more than one newsgroup.

[toc] | [prev] | [next] | [standalone]

#17516

On 6/30/2017 12:39 AM, Gordon Burditt wrote:
>> That's true.   But a connection is also etheral.  
> 
> I don't know what that word is, and neither does dictionary.com.
> I suspect you mean "ephemeral".
>

Etheral - as in the ether.

>> It comes and goes all
>> the time.  
> 
> No, not all of them are and not all of them are supposed to be.
> And it seems to take 45 seconds to decide that the connection
> actually has gone away if it got disconnected by the IP change
> before it gets closed.
> 

That is up to the settings in the transport layer.  Different systems
will have different settings.

> SSH, telnet, ftp, and http for big files can all last a significant
> amount of time (e.g. an hour) where an IP change is likely to
> interrupt them, and they do *NOT* automatically restart.  And if
> you cut one off in the middle by an IP change, it takes time for
> either end to realize it.  
> 

Yes, some can last.  However, that does not mean an IP change will
interrupt them.  Connections run at the transport layer, while the ip is
part of the network layer.  The transport layer is pretty well insulated
from the network layer.  And ssh, telnet, etc. are way up at the
application layer, well insulated from either of the two.

Yes, it does take a little time for either system to realize the ip has
changed.  There can be up to seven outstanding packets.  If a packet
does not get a response after some period of time, it will be retried
(network layer).  This generally takes a few seconds.  But once the
packet is retried successfully, communications continues.

> 
>> For instance, if you request a page from a web site, you will
>> get a connection.  But once your browser has retrieved the page and all
>> associated files (CSS, javascript, images, etc.), the connection is
>> close.  Another page request results in another connection.
> 
> Whether or not that is a "short" period of time depends a lot on
> how big the files are.  And if the browser connection gets cut off,
> it does *NOT* cleanly restart, there are long pauses and error
> messages, usually requiring a page reload to make the page viewable.
> 

Once again you're talking apples and oranges.  If the browser
(application layer) gets cut off, no, it will not restart.  But that is
typically when there is a problem at the server or in the path, not on
the client end.

> What is a "webinar"?  I think it involves real-time streaming
> interactive video.  To get anything meaningful out of it, a connection
> needs to last way more than a few seconds.  Since it's interactive,
> you can't download the whole thing in 2 seconds and spend 2 hours
> watching it.  (The same applies to VOIP phone calls).
> 

Where have you been?  Webinars have been around for over 20 years.  And
yes, it is a live presentation, often times 30 to 50 minutes long,
although I've seen ones which last all day (with multiple
presentations).  But once again, a change in the client's ip doesn't
break the connection; there will be a stutter while it recovers, but it
continues on.

> 
>>> One way for your IP to change would be a configuration change
>>> in the DHCP server, followed by a lease renewal.  My DHCP servers
>>> seem to like renewing the IP a client already has, but if that
>>> IP is removed from the acceptable IPs for this client, it will
>>> change.
>>>
>>
>> Or just the expiration of your current lease and the request for a new
>> one.  There is nothing in the RFC's which requires an ISP to reissue the
>> same IP upon lease renewal.
> 
> There do seem to be provisions in the RFCs which permit renewing the
> same IP without ever releasing it:  DHCPREQUEST/DHCPACK done before
> lease expiration rather than DHCPDISCOVER/DHCPOFFER.  No, the ISP is
> not required to reissue the same IP on lease renewal, and I suspect the
> server is required to NOT reissue the same IP should it no longer be
> available (e.g. a configuration change removing the IP from the pool or
> dedicating it to another system.  Or perhaps banning the renewing
> system by MAC address, in which case it gets NO IP).  
> 

And how many systems use DHCPREQUEST/DHCPACK?  I haven't seen any, anyway.

> *MY* DHCP servers seem to like renewing the IP a client already has
> unless there's a reason not to.  I also don't see any setting to
> make them not do that besides changing the configuration so the
> client isn't eligible for the IP they now have; I wanted to try it
> out once to see if a certain glitch was caused by lease renewal,
> but apparently mine don't have that feature.  Do you know of any
> DHCP servers that have documented features to force IP changes
> periodically?
> 

Nope, not currently.  But neither do I know of any DHCP servers that
have documented features to force the IP address to not change, unless
you use DHCP to effectively assign a static IP address to them (which is
how I set up printers and such on internal networks).

> I don't know what yours do.
> 

I've already explained that in previous posts.

> 
>>> If my (client) IP address changed due to renewing with a different
>>> address, how does the TCP connection survive?  I've always observed
>>> that both ends of the connection are disconnected.  Eventually they
>>> time out and go away, but this might take 45 seconds.
>>>
>>
>> See above.
> 
> Your answer seems to be that short-duration connections, such as a
> few seconds, can't be interrupted by an IP change, which is ludicrous.
> 

It is exactly what happens.  The internet is very robust.  That's why it
works.

>>
>>> NNTP connections don't survive an IP change, largely because they
>>> stay up for hours while you're reading USENET, unlike a web server
>>> which is likely to load a page and disconnect, so connections last
>>> a few seconds.
>>>
>>
>> Nope.  My connection to my usenet server is created when I request a
>> download of updates, and closes after that.  it is open for a few
>> seconds at most.
> 
> I find that difficult to believe, even assuming you've got a 10 gigabit
> connection all the way between you and your news server and nobody 
> else is using it.  I know you subscribe to more than one newsgroup.
> 

Sure I do.  And it takes maybe 30 seconds to download all of the new
messages if I haven't been on for a few days.  After that I can unplug
from the internet and read the messages should I choose.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17517

On Fri, 30 Jun 2017 13:28:34 Jerry Stuckle wrote:
> On 6/30/2017 12:39 AM, Gordon Burditt wrote:
> > SSH, telnet, ftp, and http for big files can all last a
> > significant amount of time (e.g. an hour) where an IP change is
> > likely to interrupt them, and they do *NOT* automatically
> > restart.  And if you cut one off in the middle by an IP change,
> > it takes time for either end to realize it.  

> Yes, some can last.  However, that does not mean an IP change will
> interrupt them.  Connections run at the transport layer, while the
> ip is part of the network layer.

And if the networklayer is "gone" the connection is gone as well.

> Yes, it does take a little time for either system to realize the
> ip has changed.  There can be up to seven outstanding packets.  If
> a packet does not get a response after some period of time, it
> will be retried (network layer).  This generally takes a few
> seconds.  But once the packet is retried successfully,
> communications continues.

If either of both IP addresses changes, no retry can be successful,
thus all existing connections are terminated.

Of course, a *new* connection can be initiated immediately which
is good enough for HTTP and the like. But permanent connections
like ssh et al are gone and have to be restarted.

Bye,
Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Irritierte Dirnen liebt Berlin: Stefan!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#17518

> Yes, some can last.  However, that does not mean an IP change will
> interrupt them.  Connections run at the transport layer, while the ip is
> part of the network layer.  The transport layer is pretty well insulated
> from the network layer.  And ssh, telnet, etc. are way up at the
> application layer, well insulated from either of the two.
> 
> Yes, it does take a little time for either system to realize the ip has
> changed.  

You are describing a potentially severe TCP connection hijacking
vulnerability which I don't believe exists, at least not in this
simple form.  

From the point of view of the server, how does it tell the difference
between an IP change or the much more likely situation that the 
client:
	(a) lost power
	(b) lost its dialup connection
	(c) had its network disconnected, or
	(d) is in the process of rebooting
In both cases, the server keeps retrying sending a packet, and it
never gets any responses back, except possibly RST packets.

> There can be up to seven outstanding packets.  If a packet
> does not get a response after some period of time, it will be retried
> (network layer).  This generally takes a few seconds.  But once the
> packet is retried successfully, communications continues.


A TCP connection consists of a unique set of:
	Server IP address
	Client IP address
	Server port
	Client port

If you change one of these (at the endpoints of the connection),
it's *NOT* the same connection as before and it shouldn't affect
that connection, which is now dead, even if neither end realizes
it yet.  (If you change the IP address of one of the intermediate
routers, this shouldn't cause a problem).

If the server sends a packet with the old client IP address, it
won't even REACH the client (it no longer has that IP).  It will
reach some other system assigned that IP, which will send back a
RST packet, or a router will notice that there's no system with
that IP on the network, and drop it.  The server can retry all it
wants; it will not get the packet back to the original client (unless
the client changes its IP back to the original one, or starts up a
new connection with the new IP).

If the client sends a packet with the new client IP address to the
server, the server will try to associate it with a connection, find
that there isn't any existing connection with the new IP address,
and drop it, sending a RST packet back to the client.  The client
can retry this forever and it will not work, again assuming the
client IP address is not changed back to the original one.

The only fix here is for one end (the client) to abandon the old
connection and re-establish a new connection with the server, and
do whatever it is to set up the state of the aborted session.  (HTTP
is stateless.  Cookies, the contents of the server database, pages
with dynamic content, etc. aren't.)  The server will eventually
abandon its connection when all of the retries fail.

What prevents me from taking over a TCP connection from a client?
I'm on the same network as the client, so I send the server a packet
with my IP, which is slightly different from the IP of the original
client.  If necessary, I "accidentally" trip over the power cord
of the original client so it doesn't respond.  Is the server going
to let me use the original client's connection with the new IP?  I
sure hope not.  Note that I have a much better chance of hijacking
a TCP connection if I knock the original client offline, then change
my IP to that of the original client.


>> What is a "webinar"?  I think it involves real-time streaming
>> interactive video.  To get anything meaningful out of it, a connection
>> needs to last way more than a few seconds.  Since it's interactive,
>> you can't download the whole thing in 2 seconds and spend 2 hours
>> watching it.  (The same applies to VOIP phone calls).
>> 
> 
> Where have you been?  Webinars have been around for over 20 years.  And

True, but I don't think the word "webinar" has been around that long
with the specific implication of the presentation being real-time
and interactive.

> yes, it is a live presentation, often times 30 to 50 minutes long,
> although I've seen ones which last all day (with multiple
> presentations).  But once again, a change in the client's ip doesn't
> break the connection; there will be a stutter while it recovers, but it
> continues on.

I don't believe that's possible unless it re-establishes a TCP
connection.  If it realizes there's no data, which it can probably
determine faster than for a ssh session that can legitimately sit
idle for minutes while the user gets coffee, it can re-establish
the connection quickly.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web