This object is in archive! 

Live tracking not compatible with HTTPS?

elmuSSo shared this problem 11 years ago
Solved

I just started experimenting with Live Tracking and I already found a problem. HTTP works fine, but HTTPS doesn`t. Is that right? Nobody spotted that before? Nobody interested in secure position exchange? Am I really the only one? Or did I do something wrong and the HTTPS works fine?

Replies (13)

photo
0

Hello elmuSSo,

photo
0

Because I`m building my own service. I refuse to share my private position on unencrypted channels.


I built a HTTP/HTTPS service based on PHP to which I`m sending GET or POST request from Locus. When I`m using normal webbrowser, both HTTP and HTTPS are accepted by a server (parameters are successfully sent and acknowledged). But when I`m using Locus, only HTTP request are successful. No requests are being received by my service when I`m using HTTPS.


Btw, is there any way to debug it?


I must say, there should be some feedback received by Locus to be sure that the data was successfully sent. I thought it might be a good idea to:


1. Configure Live tracking functionality to wait for certain message coming from a web server ( eg. "OK" http response, coming back in form of plain text )


2. Change Live tracking icon colour (green red (like GPS icon colours)) to inform a user if the last sent position was successfully received

photo
0

So I built this web service and now I`m generating a kml (network link ) which I want to load in Locus. When I`m using HTTP to get my online kml file, everything is fine. But when I`m trying to get this file via HTTPS - guess what. "Problem with internet connection". This should go to the new Problem thread, but it is related to the similar issue so I will keep it here.


Please acknowledge this. Locus doesn`t support HTTPS in at least two places.

photo
0

elmuSSo wrote: Nobody interested in secure position exchange?


nope...

photo
0

and I`m sad

photo
0

don`t be :)


do you believe me I have no idea how HTTPS system works? As I see in Google documentation http://developer.android.com/training... , there is need for some certificates etc. Do you have any experiences with Android & HTTPS?


I`ll spend some time on this topic (https) next week. We`re just working on new system for communication between locus and own server and here is also planned secured http protocol, so I`m sure, it will help also here

photo
0

Thanks for answer.


Unfortunately I don`t have any experiences in that field. I`m happy you will do something in this matter. Let me know if you will have any further questions or tests.

photo
0

https is also a server side thing.


isn`t it?

photo
0

it is, but all normal webservers ( like Apache ) have it configured and ready to use.

photo
1

From network point of view, locus lacks:

- encryption (any kind, download/upload including https, encrypted sms position, etc.)

- traffic redirection through proxy (all, or selected), or designated remote redirector

- location sending queue with "try to send all data till death" feature.

- location sending queue offline memory (queue saved in file, and Locus retaining data even when system has crashed. Data should be sent after restart.)

- online kml fetching every 10 seconds, even when kml is extremly simple (two <Placemark>'s), takes A LOT of battery. About 3 times more than normal. Don't know if this problem is with locus itself or android network subsystem load. Will test more. Also some graphical minor issues for "online points" when moving map, but this is not really a problem.


ps. https doesn't need to be fully implemented with cert chains and all other crap.

Simple "remember" for a certificate (ie. fingerprint + common name) would be enough.

In the current world which surrounds us, I can assure You, certain "organizations" can generate VALID certificate chains for whatever site (common name) they wish for. It's really more secure to use your own certs.


ps2. One more thing about network. GSM (3g/edge/hspa) is often not very reliable. It would be nice, to create redirecting server, which would PUSH (ie. via UDP) requested data via network, even with option to double send packets for really bad network condition.

TCP congestion algorithms are really pain-in-the-ass when GSM drops packets or reorders them.

But this is just an idea, and would need lots of test in GSM environment.

photo
1

Good day elmuSSo. What is status of this quite old topic. Not sure if you are/were working on your private service. In Locus, nothing changes around https support, anyway we use https for own live tracking solution and also for communication with Locus Store and there are no problems. Important here should be, that we use Google services, like App Engine and similar, so it's Google <-> Google communication.


If you have any idea, how I may help here, let me know.

photo
1

Any progress on this? seems to be related to: http://help.locusmap.eu/topic/live-tracking_2


I'd also like to build my private tracking server (with traccar) to track a couple cars, which must not be public accessible.


I can't see a option for user/passws when setting up a custom live tracking.

photo
1

Good day,

I believe that HTTPS connection should not cause any troubles. It depends on certificate agency used on your server. If your agency is on device you use, there should be no problem and all should work as expected. If certificate is missing, you firstly needs to install it on your (users) device.


Option to insert name/pass .. you may include these values into "Variables" as "Text field".


@elmuSSo : any progress? Which certificate is used on your server?

photo
1

Hello guys,

may someone who has problems with this, write some info about it? Mainly if there is still any issue.


@not_a_robot : as I wrote, HTTPS should work without a problems and using name/pass may be done over custom variable values


I'm for now closing this ticket and feel free to give me some comment here in case of any troubles I may help with.

Replies have been locked on this page!