**** BEGIN LOGGING AT Sun Feb 05 03:00:01 2017 Feb 05 04:04:42 My guess is that with the cert issues preventing connectivity to the supl server it takes many minutes to get a lock because it has to download full data from sats over slow link Feb 05 04:05:52 yes Feb 05 04:07:13 sprt of, though I learned a *good* GPS driver (like we finally had in Neo Freerunner) can download the relevant data from sats it actually receives in less than 60s and then get a first fix Feb 05 04:08:07 aiui each sat sends its own orbit parameters and the current time once every 40s or somesuch Feb 05 04:09:34 as long as the GPS chip has enough correlators to receive all possible sats concurrently, it should get a first fix in pretty short time Feb 05 04:10:18 I almost forgot the details, GPS is complex and I last time looked into it several years ago Feb 05 04:12:00 http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html recommended Feb 05 04:14:12 http://www.colorado.edu/geography/gcraft/notes/gps/gps.html#SVData Feb 05 04:15:40 >>The GPS Navigation Message consists of time-tagged data bits marking the time of transmission of each subframe at the time they are transmitted by the SV. A data bit frame consists of 1500 bits divided into five 300-bit subframes. A data frame is transmitted every thirty seconds. Three six-second subframes contain orbital and clock data. SV Clock corrections are sent in subframe one and precise SV orbital data sets (ephemeris data Feb 05 04:15:41 parameters) for the transmitting SV are sent in subframes two and three<< Feb 05 04:21:11 full almanac however takes some 12 or 15min of glitch free reception for complete download Feb 05 04:21:48 "full" as in "has all data of all sats for the next week or so" Feb 05 04:23:03 aah >>Subframes four and five are used to transmit different pages of system data. An entire set of twenty-five frames (125 subframes) makes up the complete Navigation Message that is sent over a 12.5 minute period.<< Feb 05 04:24:02 http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif Feb 05 04:28:24 >>Signal acquisition time on receiver start-up can be significantly aided by the availability of current almanacs<< Feb 05 04:30:17 only useful when you already have a rough idea of where you are and what's the time, otherwise you don't know which sats are visible and on which doppler shift, even with absolutely complete and up-to-date almanac# Feb 05 04:31:08 rough idea here means like +-500km and +´1min I guess Feb 05 04:32:36 nice: http://www.colorado.edu/geography/gcraft/notes/gps/gif/bitsanim.gif Feb 05 04:32:44 corellator Feb 05 04:38:20 >>Receiver position is computed from the SV positions, the measured pseudo-ranges (corrected for SV clock offsets, ionospheric delays, and relativistic effects), ****and a receiver position estimate (usually the last computed receiver position)****.<< Feb 05 04:41:58 the complete almanac is 37500 bit in size Feb 05 04:42:14 so ~5kB Feb 05 04:43:01 it describes the orbits of all SV (aka SAT) and stays valid until reality differs from clean math Feb 05 04:45:22 the ephem are obviously per SV and describe its current position, so this is all a GPS chip needs when actually receiving the SV. Those are sent every 30s Feb 05 04:51:07 so with 4 corellators locked to 4 sats (which are sufficiently distant from each other) you should get a first fix in 30s. Locking to a sat depends on using the right code and right doppler frequency shift, and given both are correct it shouldn't take longer than a second or 2 maybe. so with an unlimited number of corellators so you can search for all possibe sats/codes at all possible doppler shifts, you always get TTFF <40s Feb 05 04:51:47 unless no sufficiently good sat signals available Feb 05 04:53:37 almanac helps to pick the right code (aka SV) and doppler correction, from estimation of point in time and space Feb 05 04:55:16 when your almanac is bogus or your time or location guess is totally off, and the GPS chip has no smart handling of that, you might find the chip trying forever to receive SVs that don't exist where amd when you are Feb 05 04:57:51 it's like staring west on a ship heading north, to find that island, and you never will see it since you're a tad further to the west than you thought you were and the island shows up in the east of your position Feb 05 04:59:54 you'll recover from that as late as seeing another random island west of you, maybe days later Feb 05 05:01:40 in case of GPS it never will recover since it not only looks for any island but for a very particular one, and it ignores resp doesn't even see any others that come by Feb 05 05:02:41 that's why I think in certain situations disabling AGPS **and RRLP** might actually yield better results Feb 05 05:03:28 So it looks like we need to find out just what certs supl.nokia.com actually needs and why it needs old/obsolete certs that Mozilla no longer ships or whatever (or if there is something else going on) Feb 05 05:03:51 And then if we really need old certs we need to add back just the one cert needed Feb 05 05:04:27 yep Feb 05 05:05:20 I *guess* the CA of those Nokia SUPL certs is expired or revoked, and Nokia didn't bother to get a new cert Feb 05 05:06:50 I dont know enough about certificates or SSL to know how to do this Feb 05 05:06:52 or the cert uses an encryption or whatever that has been deprecated since Feb 05 05:07:48 I think from something I saw is one cert that uses MD2 signing (which is obsolete and Feb 05 05:07:54 obsolete and easily broken Feb 05 05:11:08 well the certificate for supl.nokia.com is current and valid from Feb 18 2016 to May 15 2017 so its definitely not some old obsolete job Feb 05 05:27:28 Need someone who knows more about SSL (or maybe someone who knows more about VeriSign certificates in particular) Feb 05 06:26:35 Finding someone that knows about SSL certs is going to be hard though... Feb 05 07:49:51 regarding gps fix, i've just tested on my n900, cellmo: on, wifi: off, method: gnss Feb 05 07:50:15 it took ~10 minutes, all sats are in 19-31dB range Feb 05 07:50:34 started with a few (1-3) now seeing 8 Feb 05 07:51:01 accuracy 40-140m Feb 05 07:51:56 stock fw Feb 05 08:16:04 but does it differ from place to place? Feb 05 08:16:28 that's a question for me? Feb 05 08:16:32 i mean are those satellites spread evenly on sky Feb 05 08:16:54 KotCzarny: for no one especially Feb 05 08:17:13 more of a rethoric q :) Feb 05 08:17:59 yeah, they should be all over the globe Feb 05 08:18:19 but in geostationary positions, ie. not moving tiny bit relative to earth Feb 05 08:19:20 what differs is visibility (clouds, buildings) and noise/interferences (e-m noise) Feb 05 08:27:34 KotCzarny: not geostationary no Feb 05 08:32:53 no? Feb 05 08:34:05 nope Feb 05 08:35:06 fun Feb 05 08:35:16 how do they calculate their own position? Feb 05 08:35:30 or is it done from earth observatories? Feb 05 08:43:38 known/corrected from earth I suppose Feb 05 08:44:05 or adjusted according to star visibility/positions, or most likely both Feb 05 08:44:11 perfect way to confuse receivers in case of war Feb 05 08:44:12 :) Feb 05 09:00:43 jonwil: the naming order of certificates matter Feb 05 09:01:01 verisign cert used by supl is in the logs ^^^ Feb 05 09:01:24 jonwil: 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 Feb 05 09:01:44 there are two of those, one with -1 appended to the name Feb 05 09:02:11 and - you don;t need sats at all to get fix when using AGPS Feb 05 09:02:24 What I have found is that with the latest mozilla cert store, openssl returns X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN Feb 05 09:02:32 :nod: Feb 05 09:03:06 could you dump cert chain? Feb 05 09:03:12 and pastebin it Feb 05 09:03:26 openssl s_client has an option to dup cert chain and certs used Feb 05 09:03:30 *dump Feb 05 09:04:04 jonwil: ah, it seems ilew found the missing one Feb 05 09:04:19 just add it back to cert store and we should be fine Feb 05 09:04:58 anyone know how to get GDB to print the address at which the binary you are debugging is actually loaded at? Feb 05 09:05:45 jonwil: info modules? Feb 05 09:05:48 no, wait Feb 05 09:06:09 it is "info something", but I cant remember that exactly Feb 05 09:06:45 jonwil: try with "info shared" Feb 05 09:08:03 found it, "info files" gives me the address I need Feb 05 09:08:28 ok Feb 05 09:08:34 good to know Feb 05 09:08:48 Presumably you could just look at /proc/*/maps Feb 05 09:09:01 * Maxdamantus suspects `info files` pretty much does that. Feb 05 09:09:06 jonwil: however, may i have a cert chain dump? Feb 05 09:09:24 how do I get a cert chain dump? Feb 05 09:10:02 jonwil: add "-showcerts" to openssl s_client command Feb 05 09:11:17 Will do that soon and see what I get on the N900 Feb 05 09:12:35 I ran nss tstclient.exe locally earlier (built NSS on my windows box) and the chain that I got from there was http://pastebin.com/RZ0z259R Feb 05 09:13:03 So that's what supl.nokia.com servers to tstclient.exe on my w7 box Feb 05 09:13:33 The last one in the chain implies that its signed with MD2 (very strange) Feb 05 09:17:07 I suspect whats going on is that one of the 3 VeriSign certs in the chain has been replaced with something newer that has the same public key and name and that somehow openssl (which is what location-proxy uses to do its SSL) is using the old version in the certificate chain rather than the newer version in the root CA store. Feb 05 09:17:25 Going to run the s_client test now Feb 05 09:17:36 jonwil: yes, this is what happens Feb 05 09:17:51 but, s_client test will pass on n900 Feb 05 09:18:01 iirc Feb 05 09:18:18 as openssl is smart enough to use the correct certificate Feb 05 09:19:51 http://pastebin.com/TeE3jF3m Feb 05 09:19:58 That;s the openssl certificate chain dump Feb 05 09:20:19 mhm Feb 05 09:20:29 but, cmcli will fail; Feb 05 09:21:28 I wonder if its poossible to use IDA to do remote debugging on a N900 via gdb or something Feb 05 09:22:19 yes, but you need to set sysroot Feb 05 09:22:41 which means to copy rootfs to a local dir on your pc Feb 05 09:22:57 and gdbserver on n900 I guess? Feb 05 09:23:00 yes Feb 05 09:23:20 jonwil: I guess you can use ScratchBox directories for that Feb 05 09:26:11 ok, so I established the IDA remote debugger doesn't run on the N900 so that's definitely out Feb 05 09:26:29 hmm? Feb 05 09:26:39 do you run gdbserver on n900? Feb 05 09:26:51 I dont think I have a gdbserver binary Feb 05 09:26:56 wait I do Feb 05 09:27:00 well, no way then Feb 05 09:27:03 not sure how to run it though Feb 05 09:27:20 install gdbserver, and run it with --attach parameter Feb 05 09:27:35 what do I pass for the parameters to --attach? Feb 05 09:27:37 "gdbserver --attach $pid :1234" Feb 05 09:27:53 1234 is the port it listens on Feb 05 09:28:03 change it as you wish Feb 05 09:29:09 jonwil: also, if the process you want to debug is started via maemo-launcher, make sure to attach to the pid with larger id, from the bothe you have for the same binary Feb 05 09:38:54 ok, well that didn't tell me much other than that openssl is returning that X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN Feb 05 09:39:04 i.e. it confirmed what I already knew about how the function worked Feb 05 09:40:06 jonwil: which function? Feb 05 09:40:20 the function I was studying was sub_CF90 Feb 05 09:40:36 which binary ? :) Feb 05 09:40:54 location-proxy Feb 05 09:41:23 * freemangordon tries to find where his lication-proxy IDA db is Feb 05 09:42:06 It looks like if SSL_get_verify_result returns non-zero, it prints the "host: %s not verified, result: %ld" error Feb 05 09:42:09 via g_log Feb 05 09:42:22 yes, it returns 19 (self-signed cert) Feb 05 09:42:22 and it passes 2 as the first parameter to las_socket_open_response_ntf Feb 05 09:42:36 it is visible in the syslog Feb 05 09:42:37 otherwise it skips that error and passes 0 for the parameter to las_socket_open_response_ntf Feb 05 09:43:20 jonwil: I suspect it is SSL_connect that fails Feb 05 09:43:56 "Socket to %s opened, fd=%d, verify_res=%ld" Feb 05 09:44:19 ok, so I am playing some more with the nss tools on Windows. Feb 05 09:44:33 how's that going to help? Feb 05 09:44:35 which btw have the same set of root CAs built into them as my n900 Feb 05 09:44:44 I am playing more to see just what the chain looks like Feb 05 09:44:47 and how it validates Feb 05 09:45:19 using vftserv.exe from those tools I get 4 certificate files (cert.000, cert.001, cert.002, cert.003) which match the 4 certs in our chain Feb 05 09:45:28 mhm Feb 05 09:45:43 If I then run vfychain.exe on those files and pass it just cert.000, it says the chain is bad Feb 05 09:45:54 If I pass it cert.000 and cert.001, it says "chain is good" Feb 05 09:46:05 jonwil: did you pass -CApath to openssl s_client command? Feb 05 09:46:07 same if I pass it 000, 001, 002 Feb 05 09:46:13 yes I did pass -CApath Feb 05 09:46:18 and it fails? Feb 05 09:46:51 Ok so we have 4 certificates in this chain Feb 05 09:46:53 supl.nokia.com Feb 05 09:46:54 sorry Feb 05 09:46:59 Symantec Class 3 Secure Server CA - G4 Feb 05 09:47:13 VeriSign Class 3 Public Primary Certification Authority - G5 Feb 05 09:47:25 Class 3 Public Primary Certification Authority Feb 05 09:48:38 I think that there is a new version of the cert named "VeriSign Class 3 Public Primary Certification Authority - G5" in the current root CA store Feb 05 09:48:46 yes, there is Feb 05 09:49:30 it seems ssl tries to verify only against the first certificate in the store Feb 05 09:49:42 and when it is the old one, it fails Feb 05 09:52:57 I think what's happening is that in the case of this particular chain OpenSSL will only verify the last CA in the chain. Feb 05 09:54:22 i.e. it sees the last cert in the chain (the one with issuer "OU=Class 3 Public Primary Certification Authority,O="VeriSign, Inc.",C=US" and subject "OU=Class 3 Public Primary Certification Authority,O="VeriSign, Inc.",C=US" Feb 05 09:54:34 then it says "do I have a match for that cert in my root CA store" Feb 05 09:54:55 since the answer is no, it says "it must be self signed then" and returns the error Feb 05 09:55:05 but there is a match Feb 05 09:55:09 ok, there is a cert Feb 05 09:55:36 there is no match for the last cert in the chain in the root CA store as of the latest Mozilla certificate set. Feb 05 09:56:55 why it is removed? Feb 05 09:57:09 or it has never been there Feb 05 10:01:48 ok, I am looking at maemo-security-certman now Feb 05 10:03:31 jonwil: if we miss a certificate, how's that related to maemo-security-certman? Feb 05 10:03:48 maemo-security-certman contains the root CA store Feb 05 10:03:57 hence why its where I need to look Feb 05 10:07:24 ok, so I am looking at the last Nokia commit to this repo and I see 2 different certificates with the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 value Feb 05 10:09:46 They have identical values for most of the fields (including issuer and subject) Feb 05 10:09:58 The differences are a difference in the not-after date Feb 05 10:10:05 and a difference in the serial number Feb 05 10:10:10 and a difference in the signature Feb 05 10:10:16 One uses md2WithRSAEncryption Feb 05 10:10:23 the other uses sha1WithRSAEncryption Feb 05 10:11:01 The one named 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem in this particular repo revision is the md2 version Feb 05 10:11:10 and the one named 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem is the sha1 version Feb 05 10:11:27 jonwil: you're reinventing the wheel :) https://github.com/community-ssu/maemo-security-certman/commit/2cbd96e89d7529e1ce25801824fb76f39b05b836 Feb 05 10:11:45 I know about that commit, I am just chasing up the entire history of the repo Feb 05 10:12:28 jonwil: https://talk.maemo.org/showpost.php?p=1370304&postcount=122 Feb 05 10:13:21 jonwil: it might be a bug in c_rehash actually Feb 05 10:14:08 there are 2 different issues here, the first has to do with the order in which certificates appear when there are multiple versions of the same cert Feb 05 10:14:19 That one is what the commit you linked to is aiming to fix Feb 05 10:14:24 or rather it fixed Feb 05 10:14:39 :nod: Feb 05 10:14:42 The right fix is to properly fix maemo-security-certman so it orders them correctly Feb 05 10:15:01 mhm Feb 05 10:16:04 jonwil: so, we should add code on top of https://github.com/community-ssu/maemo-security-certman/commit/5b66292b9d705f9e9613490aafc074bfeef6a622 right? Feb 05 10:16:49 jonwil: also, what means "orders them correctly" do we know the rule? Feb 05 10:17:33 the newest should become last? or what? Feb 05 10:19:50 what I am trying to figure out now is how it determines whether to use the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem or the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem file Feb 05 10:19:59 mhm Feb 05 10:20:23 but isn't it ssl that makes the decision, not certman? Feb 05 10:23:24 jonwil: do you have an idea *who* decides on which cert file to use? Feb 05 10:26:37 Either the code in maemosec_storage.cpp decides when it builds the file list or the file list contains both and therefore both get passed to SSL_CTX_set_cert_store from maemosec_certman_collect Feb 05 10:26:55 maemosec_certman_collect just returns the contents of the storage as set up by the code in maemosec_storage.cpp Feb 05 10:29:32 jonwil: ok, it seems I am not very helpful with my question :). Will leave you digging in it as I have to run anyways Feb 05 10:29:37 *questions Feb 05 10:29:49 good luck, bbl Feb 05 10:40:30 Ok so as of now Mozilla doesn't ship either version of the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 certificate Feb 05 10:50:22 hmm Feb 05 10:50:54 too old? Feb 05 10:58:19 jonwil: update cert package and let sicelo test it? Feb 05 11:02:03 tbh, some things should be pushed straight away Feb 05 11:02:10 like updated system certificates, etc Feb 05 11:14:27 minor updates that are done so the OS is up to date Feb 05 11:14:36 things that do not affect stability Feb 05 11:14:41 or usability Feb 05 11:31:45 Juesto: certs do affect stability though :-) Feb 05 11:32:43 oh really? Feb 05 11:33:05 or usabiltiy then Feb 05 11:33:15 nah Feb 05 11:33:27 by usability i mean user experience Feb 05 11:34:03 it wasn't nice to need Maps, and have to wait 10 mins for GNSS fix, as A-GNSS was broken by 'new' certs Feb 05 11:34:22 Oh :/ Feb 05 11:34:29 well something like a timezone update Feb 05 11:34:32 isnt a big deal either Feb 05 11:34:41 but i guess certificates is a breaker Feb 05 11:35:08 sorry to hear Feb 05 11:36:38 maemo's devs are doing super good job though :-) Feb 05 11:38:29 heh Feb 05 11:39:05 you can be a dev too! Feb 05 11:39:21 who knows Feb 05 11:39:35 Depends on your talent/skill Feb 05 11:40:04 my skills is talking too much :p Feb 05 11:40:46 you would serve well for reporting then Feb 05 11:40:47 hehe Feb 05 11:49:58 yeah, maemo needs more testers Feb 05 11:55:08 i wish i have a n900 Feb 05 11:55:10 really Feb 05 11:58:52 buy usb broken one (that has not been fixed before) Feb 05 11:59:05 then fix yourself Feb 05 12:01:18 hmm, perhaps i'll just take from oksana :) Feb 05 12:01:29 (yes she lets me) Feb 05 12:01:36 AFAIK Feb 05 13:27:51 well, the package that broke certs in is cssu-dev, so everything is as it should be - we devs screw something in unstable repo, users test and report, we fix it Feb 05 13:28:28 jonwil: if neither certs are in mozilla store, then we should add it by hand Feb 05 13:28:33 I see no other option Feb 05 13:29:09 maybe we should not use mozilla, but debian Feb 05 13:32:07 fmg: or make a script that will repackage what's needed Feb 05 13:32:47 mhm Feb 05 13:33:31 i would trust mozilla more than debian to be honest too Feb 05 13:34:28 KotCzarny: hmm, actually all the certs I have on my Ubuntu are from mozilla :) Feb 05 13:36:17 so yeah, mozilla it is Feb 05 13:39:55 hehe Feb 05 14:40:16 I am testing a fix now Feb 05 14:40:47 involving a 2-byte patch to location-proxy and installing the certificate into a separate private certificate store. Feb 05 14:41:48 the fix works :) Feb 05 14:44:05 http://talk.maemo.org/showthread.php?p=1522859&highlight=00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61#post1522859 Feb 05 14:48:09 jonwil: I am not sure I like the idea of binary patching the location proxy Feb 05 14:48:24 we binary patch libsms.so for the cell broadcast stuff already Feb 05 14:48:26 thats in CSSU Feb 05 14:48:50 that doesn;t mean I like it :). however, see: Feb 05 14:49:59 what about including those 2 certs until I RE location-proxy. anyway I will do it sooner or later, because of the fremantle porting. it is some 30k binary I guess I'll need a month or less to finish Feb 05 14:50:31 those 2 certs been there forever a month more will not do that much harm Feb 05 14:50:40 if any Feb 05 14:51:20 jonwil: ^^^? Feb 05 14:51:35 except the whole point of keeping the root CA store up to date is to not ship insecure broken certs using insecure broken cryptography Feb 05 14:51:53 how's that related? Feb 05 14:52:27 that we'll use those 2 presumably broken certs for a month or so? Feb 05 14:53:47 jonwil: also, I don;t get it why lokation-proxy fails while openssl does not Feb 05 14:53:57 *location-proxy Feb 05 14:54:27 what is this special thing it does that makes it fail? Feb 05 14:55:29 jonwil: any idea? ^^^ Feb 05 14:55:33 no idea Feb 05 14:56:13 because this is the actual problem imo. I tested openssl tu supl.nokia.com on my Ubuntu and there is no problem Feb 05 14:56:18 *to Feb 05 15:15:55 The reason openssl works is because at some point you had the relavent root CA (the old insecure one) in your CA store but now you dont anymore.. Its no longer in /etc/secure/s/certman.common-ca and wont be used by anything that uses libmaemosec-certman0 to get certificates (including NSS and location-proxy) but will still be found by openssl when you pass -CApath in the verify command Feb 05 15:16:23 since openssl doesn't read certman.common-ca, it just uses whatever is in the passed in capath Feb 05 15:16:52 jonwil: read it again - it doesn't fail *on my Ubuntu* Feb 05 15:17:00 Your ubuntu must also be shippnig the cert Feb 05 15:17:06 for some reason Feb 05 15:17:14 it ships the mozilla stuff Feb 05 15:17:35 what does the certificate chain look like on your ubuntu install? Feb 05 15:17:42 just a second Feb 05 15:17:47 and what openssl version is it? Feb 05 15:18:25 Its possible that you have a newer version of something somewhere that properly says "hey, dont use this old root CA in the certificate chain, use the newer correct replacement in the root CA store" Feb 05 15:20:09 jonwil: well, lets identify it and port it to maemo then Feb 05 15:20:17 jonwil: http://pastebin.com/EZcxfFjp Feb 05 15:21:55 What's the contents of /etc/ssl/certs/? Feb 05 15:22:06 it is huge Feb 05 15:22:13 lots of files there Feb 05 15:22:31 do you want me to pastebin it? Feb 05 15:22:51 yes please do Feb 05 15:22:54 ok Feb 05 15:24:04 jonwil: http://pastebin.com/b3WHxKk3 Feb 05 15:26:09 Can you pastebin Verisign_Class_3_Public_Primary_Certification_Authority.pem? Feb 05 15:26:24 I bet it (or Verisign_Class_3_Public_Primary_Certification_Authority_2.pem) will be the certificate from the chain Feb 05 15:26:38 the self-signed one Feb 05 15:27:14 it is a link to /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt so I'll pastebin the .crt file Feb 05 15:27:23 ok Feb 05 15:27:56 jonwil: http://pastebin.com/acjQ3EgK Feb 05 15:28:44 yep, just as I suspected, its exctly the root CA in question Feb 05 15:28:54 the one with the outdated crypto Feb 05 15:29:01 the one in the chain from supl.nokia.com\ Feb 05 15:29:13 and no I dont know why its on your Ubuntu system in that place Feb 05 15:29:25 you would have to ask the maintainer of whatever package claims ownership of the relavent files... Feb 05 15:29:42 well, if it is good enough for my Ubuntu, it is good enough for my Maemo as well :) Feb 05 15:30:07 I don;t really see what is the problem with that certificate, besides weak hash Feb 05 15:31:07 Maintainer: Ubuntu Developers :) Feb 05 15:31:20 Its the fact that its using a very weak 1024 bit RSA key, something that all the browser vendors and other sane people have stopped shipping for ages now Feb 05 15:32:07 1024 bit RSA is weak? O.o Feb 05 15:32:30 jonwil: who told you that? Feb 05 15:36:43 https://supportforums.cisco.com/discussion/11320131/https-ssl-certificate-signed-using-weak-hashing-algorithm Feb 05 15:37:02 The CAB forum (which sets rules that CAs need to follow if they want to be in the major browsers) has declared that all CAs must use RSA keys of at least 2048 bits if they want to remain in the browsers Feb 05 15:37:11 And there was a big effort to get all the old certificates retired Feb 05 15:37:24 including the VeriSign one at the heart of this discussion Feb 05 15:37:32 fmg, see the description there and it has more reading too if you want to pursue further details Feb 05 15:38:15 That discussion means nothing in the context of this discussion Feb 05 15:38:35 it describes why weak hashing algos are bad Feb 05 15:38:37 There is nothing wrong with the hashing algorithm of the certificate in question since its a root CA Feb 05 15:38:48 and why it's bad to have such CAs Feb 05 15:38:59 see, as part of my job I am dealing with PCI-DSS stuff on a regular basis, so I have a clue Feb 05 15:39:01 in this case we are interested in why 1024-bit RSA is bad Feb 05 15:39:16 yes, exactly Feb 05 15:39:20 and why shipping a cert in the root CA store that has a 1024 bit public key is bad Feb 05 15:39:38 jonwil: but, this is when it omes to new certificates Feb 05 15:39:42 If all the major CAs AND all the major browser vendors all say that a 1024 bit RSA key is too weak, I am inclined to trust them Feb 05 15:39:42 *comes Feb 05 15:39:48 All of them got rid of 1024 bit certificates Feb 05 15:40:27 and no 1024 bit certificates (old, new or otherwise) will be treated as trusted by any of the major browsers in whatever version it is Feb 05 15:40:37 jonwil: ever thought that it is all about the money? Feb 05 15:41:04 there is no evidence so far that 1024 bit RSA was ever broken Feb 05 15:41:32 ..yet Feb 05 15:41:57 yes, yet Feb 05 15:42:53 jonwil: and I bet all the stable releases of all the major distribution have the certificate in question included Feb 05 15:43:03 *distributions Feb 05 15:43:48 so, lets not overengineer Maemo and let simply include that(those) certificate(s) Feb 05 15:46:48 NSA will crack them easily ;-) Feb 05 15:46:57 from the CAs POV it looks like - dammit, we've issued root certs that expire in more than 10 years from now...hmm...how to fill the budget for the next couple of years? aah, BINGO, lets tell them that all the 1024 bit certs have to be replaced because in a couple of years quantum computers most probably will be powerful enough to factor 1024bit RSA. Feb 05 15:47:20 :) Feb 05 15:47:42 or that, yes Feb 05 15:47:42 fmg, what if they are crackable by invering in big farm? Feb 05 15:47:53 DocScrutinizer05: I doubt breaking RSA can be kept secret for long Feb 05 15:47:58 KotCzarny: no way Feb 05 15:48:08 in similar way there are 'sploits running on black market Feb 05 15:48:30 so maybe there is such black farm or more than one? Feb 05 15:48:39 KotCzarny: afaik, anything > 512 is not feasible Feb 05 15:48:51 or maybe anything > 768 Feb 05 15:49:15 1024 sounds *very* long, didn't they crack 56bit or sth, with distributed computing, in years? Feb 05 15:49:15 you know, exponential Feb 05 15:50:00 yeah Feb 05 15:50:18 Even the long term stable versions of browsers like firefox have removed the 1024 bit certificates. Feb 05 15:50:57 but how do *we* care about that? Feb 05 15:51:04 for supl Feb 05 15:51:16 DocScrutinizer05: the same certs are used Feb 05 15:51:29 for supl and www Feb 05 15:51:38 yes, and aiui Nokia didn't update their supl cert Feb 05 15:51:42 my point is that there IS a way to store the certificate so that it can be used by location-proxy but not by anything else Feb 05 15:51:56 so should we, simply don't touch it Feb 05 15:52:07 jonwil: doesn;t make sense, that cert anyway expires in 3 months Feb 05 15:52:14 how900: makes sense Feb 05 15:52:30 haha, ok then not Feb 05 15:53:00 damn, jonwil^^^ - sorry how900 Feb 05 15:54:02 let's take bets what gonna gappen to Nokia SUPL in 3 months? Feb 05 15:54:14 happen* Feb 05 15:54:32 o.o Feb 05 15:54:41 Not After : May 15 23:59:59 2017 GMT Feb 05 15:54:43 :) Feb 05 15:54:43 you rather find a way to convince proxy(?) to use an expired cert Feb 05 15:54:58 oh so much less traffic Feb 05 15:55:02 thay'll fix it, all symbian devices depend on that as well Feb 05 15:55:03 winwin Feb 05 15:55:20 ooh Feb 05 15:55:27 I don't know Feb 05 15:55:30 but how would they redistribute it? Feb 05 15:55:39 KotCzarny: distribute?!? Feb 05 15:55:44 this is server cert Feb 05 15:55:46 they might not be interested in sybian anymore Feb 05 15:56:10 arent ca certs part of os? Feb 05 15:56:19 only root ones Feb 05 15:56:19 and maybe symbian doest't care about cert expiry? Feb 05 15:56:24 no way Feb 05 15:56:45 they were in the same shit as maemo when the old cert expired Feb 05 15:57:04 the current one is "Not Before: Feb 18 00:00:00 2016 GMT" Feb 05 15:57:30 The root problem is that supl.nokia.com sends an obsolete VeriSign root certificate as part of its certificate chain Feb 05 15:57:38 why they send that obsolete certificate I haven't a clue Feb 05 15:57:57 jonwil: could you find the mozilla bug for removing that certificate? Feb 05 15:58:29 fmg, that would be probably part of the remove 1024 certs Feb 05 15:59:09 https://bugzilla.mozilla.org/show_bug.cgi?id=986005 is the bug where the root certificate in question was removed Feb 05 15:59:11 04Bug 986005: was not found. Feb 05 15:59:17 or where the decision to remove it was made anyway Feb 05 15:59:53 it ultimately got removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1021967 Feb 05 15:59:54 04Bug 1021967: was not found. Feb 05 16:01:32 (( why they send that obsolete certificate I haven't a clue)) you _really_ need to guess on _why_ here? Feb 05 16:02:20 simply same reason why maemo keys expired and thus locked nokia out to update them Feb 05 16:02:41 nokia NEVER got cert stuff right Feb 05 16:02:41 because they use some symantec intermediate which has that verisign cert in its chain Feb 05 16:04:02 anyway, IMO we should just include those 2 until 15th of May comes and see what certificate, if any will be used after Feb 05 16:04:18 exactly Feb 05 16:05:29 in the meanwhile I will be hopefully ready with location-proxy RE, so we'll be able to use whatever cert store needed, without compromising the browser security Feb 05 16:05:32 jonwil: ^^^ Feb 05 16:05:38