| 00:16.29 | *** join/#asterisk infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:16.29 | *** topic/#asterisk is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.27.0 (2019/5/30) 16.4.0 (2019/5/30), Security Only: 15.7.2 (2019/2/28); DAHDI: 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
| 00:21.31 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
| 00:28.22 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 01:14.45 | *** join/#asterisk troyt (zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) |
| 01:21.15 | *** join/#asterisk ruben23 (~Opendial@49.151.227.207) |
| 02:15.05 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:a453:6053:e9c0:bace) |
| 02:18.04 | *** join/#asterisk ghoti (~paul@glphon2233w-grc-09-184-145-52-216.dsl.bell.ca) |
| 03:46.45 | *** join/#asterisk nohop (~nohup@chef.nohup.nl) |
| 04:07.39 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:07.19 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 06:16.13 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 06:52.56 | *** join/#asterisk jkroon (~jkroon@105.12.6.235) |
| 07:15.30 | *** join/#asterisk jkroon (~jkroon@105.12.6.235) |
| 07:23.34 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
| 07:41.40 | *** join/#asterisk jkroon (~jkroon@105.12.6.235) |
| 08:21.45 | *** join/#asterisk jknotten (~jknotten@82-71-28-175.dsl.in-addr.zen.co.uk) |
| 08:26.29 | jknotten | I am subscribed to the localphone voip service, which provides an incoming landline number. I have two voip devices (a gigabit n300a and a fritzbox router). When there is an incoming call on localphone, only the first registered device rings. I'd like both to ring. Can asterisk help me out here? I'm planning to put the n300a and the fritzbox in two separate houses, so it'd be neat to have one number ring both places. |
| 08:34.38 | *** join/#asterisk jkroon (~jkroon@105.12.6.235) |
| 08:42.08 | *** join/#asterisk jkroon (~jkroon@105.12.6.235) |
| 09:22.15 | Reinhilde | With chan_sip you would need two separate accounts. |
| 09:26.01 | jknotten | Reinhilde, right I can do that |
| 10:12.14 | *** join/#asterisk ganbold (~ganbold@202.21.108.202) |
| 10:28.03 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@185.246.128.83) |
| 11:00.46 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:01.16 | *** join/#asterisk emsjessec (~emsjessec@96.56.225.51) |
| 11:43.55 | *** join/#asterisk jkroon (~jkroon@105.12.6.235) |
| 12:26.32 | *** join/#asterisk ChkDigit (~u388mw@74.3.144.66) |
| 12:32.15 | *** join/#asterisk catphish (~charlie@unaffiliated/catphish) |
| 12:32.23 | catphish | does anyone have any VoIP manufacturer CA certificates? |
| 12:34.18 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 12:44.24 | Samot | catphish: What? |
| 12:45.00 | catphish | i need the certificates that voip phone manufacturers use to sign the certs they install on all their devices |
| 12:46.26 | Samot | What devices are you talking about? |
| 12:47.06 | catphish | ideally, all of them, specifically polycom, yealink, snom to begin with |
| 12:48.46 | Samot | No one issues certs like that |
| 12:49.14 | catphish | all those manufacturers do |
| 12:49.48 | catphish | all new phones have such certs installed, but i'm struggling to find the CAs |
| 12:50.44 | Samot | Not valid certs |
| 12:50.59 | Samot | Selfsigned sure |
| 12:51.35 | catphish | incorrect |
| 12:51.45 | Samot | ok |
| 12:51.56 | Samot | The ones i jist bought lie |
| 12:52.18 | catphish | what devices? |
| 12:52.31 | Samot | Yealinks and polycoms |
| 12:53.09 | catphish | the ones i've tested so far (yealink and polycom) are signed singed by a manufacturer CA, the certs would be completely useless otherwise |
| 12:53.39 | file | certificates for what purpose? |
| 12:53.41 | Samot | What do you need them for? |
| 12:54.17 | catphish | they're used to authenticate requests from the phones (usually for provisioning) |
| 12:54.40 | *** join/#asterisk scgm11_ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 12:54.47 | Samot | No they are not. |
| 12:54.59 | catphish | they really are |
| 12:55.03 | Samot | No they are not. |
| 12:55.15 | Samot | If I have a SSL based provisioning server then it's MY CERT |
| 12:55.21 | Samot | At the location of the provisioning server. |
| 12:55.35 | Samot | https://phones.provision.com has nothign to do with the cert on the phone. |
| 12:55.54 | catphish | i don't know how better to explain, phones have certificates, they're absolutely used to authenticate them for provisioning |
| 12:56.03 | Samot | They absolutely are not. |
| 12:56.28 | Samot | If you use TFTP, there's no SSL |
| 12:56.37 | Samot | If you set it to HTTP, no SSL |
| 12:56.41 | Samot | Or FTP |
| 12:56.55 | Samot | So how will those non-secure methods use the cert to provision? |
| 12:57.06 | catphish | it would only work over HTTPS |
| 12:57.18 | file | I'd suggest talking to the manufacturer of how they expect the particular certificate to be used |
| 12:57.18 | Samot | Right and when you put in my provsioning URL |
| 12:57.21 | Samot | With HTTPS |
| 12:57.28 | Samot | Who's cert do you think gets used? |
| 12:58.08 | catphish | file: they just don't seem to publish the certs for some reason, i can ask for them but it's tedious :) |
| 12:58.09 | Samot | file: Polycom's make their web admin for the phone HTTPS by default. |
| 12:58.15 | Samot | But it's an invalid cert. |
| 12:59.39 | catphish | Samot: when you put in an HTTPS provisioning URL, the phone verifies the provisioning server against any of its built in CAs, and the server authenticates the phone using the device certificate, there are 2 certificates involved in such a request |
| 12:59.44 | file | I doubt they would make their CA public key available, but they may make the public available for verification of the trust chain if the device provides a client certificate |
| 12:59.53 | Samot | No there is not catphish. |
| 13:00.00 | Samot | You understand how HTTPS works right? |
| 13:00.05 | catphish | i do |
| 13:00.09 | Samot | https://google.com doesn't care about what cert YOU HAVE |
| 13:00.12 | catphish | i believe you do not |
| 13:00.15 | Samot | HAHAHA |
| 13:00.23 | catphish | Samot: that's correct, google has no reason to authenticate clients |
| 13:00.35 | file | Samot: client certificates are optional, but can be done |
| 13:00.38 | Samot | What does HTTPS have to do with auth? |
| 13:01.05 | catphish | everything :) |
| 13:01.10 | Samot | No. |
| 13:02.04 | catphish | you're just going to have to believe me that TLS optionally verifies client certificates and this is widely used for phone provisioning |
| 13:02.36 | Samot | I run provisioning servers. |
| 13:02.40 | file | I wouldn't say widely, it can be used |
| 13:02.44 | Samot | No one has certs on their phones to provision with me. |
| 13:03.12 | Samot | I have the cert because they are making an HTTPS request to _my server_ |
| 13:03.18 | Samot | Like any other HTTPS request |
| 13:03.30 | scgm11_ | hello, anyone recording video on asterisk? |
| 13:04.28 | file | barely anyone |
| 13:04.47 | catphish | Samot: well the only other way to authenticate requests is to manually enter authentication details into the phone, and that's not particularly practical for automation, it's definitely best practice to use TLS auth |
| 13:05.13 | scgm11_ | I´ve seen app_mp4 around, but cannot find the deps |
| 13:05.19 | Samot | catphish: I can set up my HTTP/HTTPS base provisioning to use a user/pass or not. |
| 13:05.31 | Samot | If they do it via HTTP then the user/pass is plain |
| 13:05.42 | Samot | If they connect HTTPS then the user/pass is secured. |
| 13:05.49 | Samot | Or I don't have a user/pass.... |
| 13:06.08 | Samot | And they can just pull their profile over HTTPS because it's just downloading files. |
| 13:06.11 | catphish | i guess in plenty of local environments, auth is not needed |
| 13:06.27 | Samot | But the phone doesn't need a cert on it for that |
| 13:06.33 | Samot | Because the provisioning server is the one with the cert. |
| 13:06.49 | Samot | It's the provisioning server that is doing the HTTPS not the phone. |
| 13:06.53 | catphish | anyway, i can't seem to find the CA certificates, so i guess i'll have to ask the manufacturers directly, just hoped someone else had them |
| 13:08.10 | catphish | yay, managed to get the certs from our distributor :) |
| 13:08.13 | Samot | The only thing a CA loaded on the phone will do is be a CA for the certs that are on the phone |
| 13:08.24 | Samot | Which means they are only used for when you connect _to the phone_ |
| 13:08.39 | catphish | i don't think that makes sense |
| 13:08.44 | Samot | OK. |
| 13:08.53 | Samot | Well I've been doing this for a very long time. |
| 13:08.54 | catphish | CAs on the phone are used to verify servers that the phone connects to |
| 13:08.59 | Samot | NO IT IS NOT |
| 13:09.10 | catphish | can't tell if you're just messing with me now |
| 13:09.28 | Samot | The only time you would need to put a CA on the phone for that is if the other side had a self-signed cert on it. |
| 13:09.49 | Samot | That's why there are Public CAs. |
| 13:10.11 | Samot | That's why browsers and other software have CAs in them already from the public CA's out there. |
| 13:11.22 | Samot | I'm not messing with you at all or in any way. |
| 13:11.29 | Samot | I'm trying to tell you how things actually work. |
| 13:11.37 | catphish | to clarify... 1) phones have public CAs installed on them, they are used to verify servers they connect to 2) you can install your own, there's rarely any need to do this 3) you can't verify a self-signed certificate |
| 13:11.58 | Samot | You can verify a self-signed cert if you load the details on the device using it. |
| 13:12.14 | Samot | Because the CA needs to be installed at that point. |
| 13:12.37 | catphish | i guess you can install the self-signed certificate at both ends, i've never done that |
| 13:13.53 | catphish | but in addition, modern phones have a device certificate signed by the manufacturer's CA, this is used to authenticate the phone during outbound TLS requests, i think polycom uses this as the certificate for its HTTPS server too, but i didn't hceck |
| 13:13.55 | catphish | *check |
| 13:14.25 | catphish | if you do provisioning over the internet, i'd strongly recommend looking into using these certificates |
| 13:14.42 | catphish | if only to avoid having to manually configure credentials |
| 13:14.55 | Samot | The phones don't need CA's for connecting to an HTTPS location that is using a public TLS cert. |
| 13:15.07 | catphish | yes they do |
| 13:15.12 | Samot | Why? |
| 13:15.16 | Samot | Why do you think that? |
| 13:15.32 | catphish | how would they verify the certificate of the server if they didn't have the CA? |
| 13:15.42 | Samot | PUBLIC CAs |
| 13:15.50 | catphish | the CA is public, but how would they get it? |
| 13:15.54 | Samot | When you get a cert from Commdo, RapidSSL |
| 13:16.08 | Samot | Because major CA vendors are TRUSTED BY OTHER VENDORS |
| 13:16.37 | Samot | Chrome, Firefox, Safari, Opera, etc they all have those CAs trusted by default. |
| 13:16.44 | Samot | So do other devices. |
| 13:16.53 | catphish | right, including phones |
| 13:16.59 | Samot | Right. |
| 13:17.07 | catphish | so the phones have those CAs! |
| 13:17.17 | Samot | Not the manufacture's. |
| 13:17.35 | catphish | we're talking about public CAs now |
| 13:17.46 | catphish | the phones have several pre-installed |
| 13:17.59 | Samot | Polycom is not a CA. |
| 13:18.02 | Samot | They don't try to be. |
| 13:18.12 | Samot | When you go to https://polycom.com they are not the CA. |
| 13:18.25 | catphish | they are a CA, i am looking at their certificate now |
| 13:18.56 | catphish | it's not trusted by browsers, but that doesn't make it any less of a CA |
| 13:19.06 | Samot | So when you go to their website.. |
| 13:19.14 | Samot | Their HTTPS cert for their site is Google CA |
| 13:19.26 | Samot | It was a cert issued by Google's CA. |
| 13:19.33 | catphish | right, they obviously wouldn't use their own CA for their website, because it's not trusted by browsers |
| 13:19.52 | catphish | but they do use it to sign the certificates they install in their phones |
| 13:20.15 | Samot | Sorry, not Google..DigiCert. |
| 13:20.46 | Samot | Right and when I got the https://phone-ip to hit the phone I get a warning. |
| 13:20.51 | Samot | That the cert isn't trusted |
| 13:20.57 | Samot | Because I don't have the CA in by browser. |
| 13:21.00 | catphish | correct |
| 13:21.06 | Samot | That is hitting the phone |
| 13:21.14 | Samot | Accessing the HTTPS server on the phone. |
| 13:21.19 | catphish | but it's not self-sighed like you might expect, it's signed by the manufacturer's CA |
| 13:21.28 | Samot | Right |
| 13:21.39 | Samot | A non-public or trusted CA. |
| 13:21.44 | Samot | That they SIGNED THEM SELVES |
| 13:22.11 | Samot | They didn't use a public/trusted CA. |
| 13:22.38 | catphish | correct |
| 13:22.46 | Samot | "self-signed" means a non-public/trusted CA signed the cert. |
| 13:22.52 | Samot | A self-serving CA. |
| 13:22.52 | catphish | no it doesn't |
| 13:22.55 | Samot | OK. |
| 13:23.01 | catphish | it means a certificate that signs itself |
| 13:23.15 | Samot | Certs get generated by the CA. |
| 13:23.31 | Samot | When you're your own CA, that is self-signing. |
| 13:24.14 | catphish | i've never known the phrase self-signed to mean that, that's very confusing |
| 13:24.20 | catphish | anyway, when that phone makes a request to your HTTPS server (ie for provisioning) it will send that same certificate, and you can (rather than any other authentication method) verify it with the manufacturer's CA |
| 13:24.36 | Samot | Well as a user you're job is to create a CRS (request) and the private key |
| 13:24.56 | Samot | You send those to the CA of your choosing. They use those to generate the CRT file. The cert. |
| 13:25.02 | catphish | remember, i know how TLS works :) |
| 13:25.13 | Samot | So the only difference is instead of sending it to a CA |
| 13:25.18 | Samot | You create the CA yourself. |
| 13:25.31 | Samot | And then gen/sign the cert against your own CA. |
| 13:25.41 | catphish | that's technically the same though |
| 13:26.01 | Samot | Except those that wish to use the cert must have the CA details. |
| 13:26.07 | catphish | the only difference is who controls the CA and whether browsers have accepted it into their default lists |
| 13:26.07 | Samot | So you need to send them that. |
| 13:26.27 | Samot | Not just the browser. ANY device/software that wants to use the cert. |
| 13:26.34 | Samot | FTP, etc. |
| 13:26.37 | Samot | Mail. |
| 13:29.13 | Samot | So if you want to create your own provisioning server and put your own signed cert on that provisioning server. You will then need to put your CA on all the phones that wish to use it. |
| 13:33.20 | catphish | that's also true |
| 13:33.52 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-ftmwevcidzpykana) |
| 13:33.52 | *** mode/#asterisk [+o bford] by ChanServ |
| 13:35.01 | Samot | So again, why do you need the manufacturer's CA? |
| 13:35.28 | catphish | to authenticate the phone when it makes HTTPS requests to my server |
| 13:35.36 | catphish | i thought i explained |
| 13:35.52 | Samot | Their CA will do nothing for that |
| 13:36.42 | Samot | Did they sign your crs and key against that CA? |
| 13:36.53 | catphish | yes it does, their CA signed the device certificate, to i can use it to verify the device certificate, which it sends when it makes HTTPS requests |
| 13:37.07 | catphish | "Did they sign your crs and key against that CA?" << yes |
| 13:37.16 | catphish | the certificate and key they embed into each device |
| 13:37.25 | Samot | So you sent each manufacture your crt and key for your provisioning server.. |
| 13:37.33 | Samot | crs* |
| 13:37.38 | Samot | And they sent you back a cert? |
| 13:37.40 | catphish | no, they install it in the device before it's shipped |
| 13:37.51 | Samot | Their CA will not authorize YOUR generated cert. |
| 13:38.00 | Samot | That's not how HTTPS works. |
| 13:38.03 | catphish | no, its their certificate |
| 13:38.10 | catphish | they generate it, and embed it into the device |
| 13:38.21 | Samot | What about the provisioning server? |
| 13:38.28 | catphish | i mean, it's mine because i bought the device, but they generate it |
| 13:38.30 | Samot | Or the SIP server? |
| 13:38.40 | catphish | the provisioning server uses a certificate signed by a public CA |
| 13:38.48 | Samot | Then you don't need their CA. |
| 13:38.54 | Samot | The HTTPS has a public CA |
| 13:38.59 | Samot | The phone knows that |
| 13:39.00 | catphish | yes i do, to verify the PHONE |
| 13:39.13 | Samot | How are you verifying the phone? |
| 13:39.30 | catphish | it's a 2-way process, the server proves its identity with a public-ca-signed cert |
| 13:39.41 | catphish | and the phone proves its identity with a cert signed by the manufacturer |
| 13:39.49 | Samot | No, it's an HTTPS request. |
| 13:39.55 | catphish | right |
| 13:40.00 | Samot | It is literally a standard HTTPS request. |
| 13:40.03 | catphish | lets back up a step |
| 13:40.13 | catphish | you know HTTPS supports 2-way auth? |
| 13:40.23 | catphish | (ie client as well as server) |
| 13:41.04 | Samot | Sure so you're doing this in a manner pretty much no provisioning servers are setup for. |
| 13:41.10 | Samot | Got it. |
| 13:41.24 | Samot | That is how you should have led this conversation. |
| 13:41.37 | Samot | That you are trying to achieve 2-way auth over HTTPS. |
| 13:41.52 | Samot | A non-standard way to setup provisioning servers for devices. |
| 13:43.10 | catphish | except it's not non-standard, it's very much best practice, and mandated by some certifications |
| 13:43.18 | *** join/#asterisk ruben23 (~Opendial@49.151.227.207) |
| 13:43.36 | Samot | Non-standard where? |
| 13:43.38 | Samot | In what sense? |
| 13:43.48 | Samot | Wildcard certs are standard. |
| 13:43.52 | catphish | that was your claim, not mine |
| 13:43.52 | Samot | SIP doesn't like them. |
| 13:44.02 | catphish | wait what? |
| 13:44.22 | Samot | The SIP RFC expressly said wildcard certs using *.domain.com are not acceptable. |
| 13:44.35 | Samot | You must specify the full FQDN |
| 13:44.36 | catphish | wow, didn't know that |
| 13:44.39 | Samot | Right |
| 13:44.51 | Samot | So when I'm talking about a phone provisioning server... |
| 13:45.16 | Samot | There are ways to do that and that might not be the same as a regular HTTPS server that does 2-way auth. |
| 13:45.41 | Samot | Do not conflate web hosting setups with SIP setups. |
| 13:45.50 | catphish | this isn't SIP, it's HTTPS |
| 13:46.07 | Samot | OK VoIP, the industry.. |
| 13:46.21 | catphish | and i can tell you for certain that TLS auth is a very standard approach to authenticate for provisioning, because from the factory, it's essentially the only method available |
| 13:46.43 | catphish | unless you manually enter credentials, which isn't useful for drop-shipping |
| 13:46.45 | Samot | Except for FTP, HTTP, TFTP that they all offer. |
| 13:47.32 | catphish | how would any of those offer authentication? |
| 13:47.47 | catphish | of course, on a LAN, authentication may not be necessary |
| 13:47.53 | Samot | Well HTTP/HTTPS do the same method of auth |
| 13:48.04 | Samot | FTP has a user/pass if you want.. |
| 13:48.10 | Samot | Because, FTP. |
| 13:48.13 | catphish | you'd have to enter those manually though |
| 13:48.17 | Samot | In the phone? |
| 13:48.20 | catphish | right |
| 13:48.22 | Samot | No. |
| 13:48.26 | Samot | I put those in the profile. |
| 13:48.43 | catphish | and how does that profile reach the phone? |
| 13:48.55 | Samot | Well depends on how I deploy it. |
| 13:49.02 | Samot | Option 66 is helpful. |
| 13:49.46 | Samot | I touch all the phones I send to customers. |
| 13:49.54 | Samot | To ensure they are on the firmware *I* use |
| 13:50.03 | Samot | And that they get the proper provisioning rule. |
| 13:50.13 | catphish | if you handle the phones and provision them on a secure LAN, that's fine |
| 13:50.26 | Samot | Then I ship them. |
| 13:50.35 | catphish | but a lot of people want to run provisioing over the internet (as i want to) |
| 13:50.42 | Samot | SO DO I |
| 13:50.55 | catphish | so stronger auth is needed, without first touching the phone |
| 13:51.02 | Samot | YOU CAN'T. |
| 13:51.05 | Samot | Wow. |
| 13:51.12 | catphish | yes you can |
| 13:51.14 | Samot | You're just sending them out without even looking at them? |
| 13:51.18 | catphish | that's the whole point of this |
| 13:51.20 | catphish | yes |
| 13:51.25 | Samot | OK. |
| 13:51.28 | Samot | good play. |
| 13:51.35 | Samot | No one is actually touching these things? |
| 13:51.37 | Samot | That's the point? |
| 13:51.41 | catphish | correct |
| 13:51.49 | Samot | So you could be sending your customers bad phones? |
| 13:51.49 | catphish | dropshipped from a distributor to customer |
| 13:51.52 | catphish | correct |
| 13:51.57 | Samot | OK. |
| 13:52.00 | Samot | I don't do that. |
| 13:52.03 | *** join/#asterisk fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 13:52.39 | Samot | I create the profile, I plug the phones into my lab. Option 66 does the rest. |
| 13:52.49 | catphish | that seems like a good approach |
| 13:52.59 | Samot | Phone provisions, updates to my firmware and I've verified it works. |
| 13:53.09 | Samot | I then ship verified/tested phones to my end users. |
| 13:53.29 | catphish | that seems sensible, but understand that people do like dropshipping |
| 13:53.44 | Samot | I like not having to deal with broken things remotely |
| 13:53.49 | catphish | and it *can* all be automated |
| 13:53.56 | catphish | well sure |
| 13:53.57 | Samot | Or having my customers mad because they have to wait longer because I sent them broken stuff. |
| 13:54.06 | Samot | Dude this is automated. |
| 13:54.06 | catphish | i'm not questioning your approach at all |
| 13:55.52 | Samot | The phones are what make the request. So "zero-touch" means the phone comes with knowing where to make the request. |
| 13:56.18 | catphish | right, this is achieved by a redirect server that the manufacturer provides |
| 13:56.39 | Samot | To my customers, I offer zero touch. |
| 13:56.59 | Samot | In order to do that, *I* have to touch the phone. |
| 13:57.03 | Samot | So they don't have to. |
| 13:57.11 | catphish | i understand your process |
| 13:57.32 | catphish | but it's not technically necessary unless you want to do your own QA |
| 13:57.47 | catphish | which again is perfectly admirable |
| 13:57.52 | Samot | Yeah, I'm weird like that. |
| 13:58.05 | Samot | I like to know the services/products I offer actually work as intended. |
| 13:59.15 | Samot | I do things like take an extra 5 minutes to do a step to avoid having a shit show in the future that could have been avoided. |
| 14:00.03 | *** join/#asterisk scgm11_ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 14:00.32 | Samot | Hell, the last two shipments for routers I got from my distributor. Two bad devices in each shipment. |
| 14:03.22 | Samot | I've gotten bad Polycoms, Yealinks. I just like to avoid the customer seeing a new phone be a brick. |
| 14:08.22 | catphish | well that does seem like it could be an annoyance |
| 14:09.50 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-lorvfjwvvlrekdis) |
| 14:09.50 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:14.27 | Samot | It is. Along with time extra time it sucks up. |
| 14:14.35 | Samot | Which is just extra costs. |
| 14:23.40 | *** join/#asterisk mazaarinqi (~mazaarinq@ip565b5ee5.direct-adsl.nl) |
| 14:31.07 | catphish | this process works nicely by the way now that i have the certs :) |
| 14:31.44 | catphish | the phone sends its cert, i verify it, and can see the MAC from the certificate |
| 14:53.40 | *** join/#asterisk beachdog (~beachdog@mobile-166-170-47-174.mycingular.net) |
| 14:58.11 | *** join/#asterisk Kaian (~kaian@212.81.221.228) |
| 15:04.40 | *** join/#asterisk ChkDigit (~u388mw@74.3.144.66) |
| 15:15.39 | *** join/#asterisk hfb (~hfb@47.139.20.234) |
| 15:22.30 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 15:22.44 | *** join/#asterisk pabe (~pabe@81.24.66.208) |
| 15:35.14 | Samot | catphish: Just remember, if part of the logic for this is extra layer of security, the whole Google Voice thing that happened last year involved people ripping certs/CAs out of valid devices and using them to spoof their PBXes. |
| 15:35.45 | catphish | this is 100% for security, and in fact i'll be trusting it completely |
| 15:36.16 | *** join/#asterisk pabe (~pabe@81.24.66.208) |
| 15:36.23 | *** join/#asterisk scgm11__ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 15:36.29 | catphish | i have to trust that each device has a unique key |
| 15:36.41 | Samot | Well Google/Polycom were on it in about 3 weeks. |
| 15:36.42 | catphish | so ripping the key from one device would be useless on another one |
| 15:36.58 | Samot | I'm not sure you have the same level of security measures they do though. |
| 15:37.09 | Samot | Well that's how people were doing it last year with Google Voice. |
| 15:37.21 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 15:37.31 | Samot | They were ripping the certs out of the Obi devices and putting them on their PBX systems to get around things for Google Voice. |
| 15:37.38 | catphish | if they were shipping private keys to consumers in devices that could be used to spoof other devices, my security is better than theirs ;) |
| 15:38.03 | Samot | It took Google Voice a couple weeks before they caught on. |
| 15:38.16 | catphish | well that's fine, as long as google were only spoofing devices they owned |
| 15:38.33 | catphish | not a huge security issue |
| 15:38.50 | Samot | No, guy A ripped the stuff from a device. |
| 15:39.00 | Samot | Then Guy A gave it to B, C, D, etc. |
| 15:39.07 | Samot | They used them on their Asterisk PBX's. |
| 15:39.30 | file | amusingly GVSIP played out as I said it would |
| 15:39.40 | Samot | Oh a few of us called that. |
| 15:39.59 | Samot | But yeah it was amusing to watch. |
| 15:44.02 | Samot | file: If you thought GVSIP was amusing, just wait for the final removal of Chan_SIP! |
| 15:44.16 | Samot | That's going to be ð¿ |
| 15:48.09 | catphish | lol |
| 15:50.49 | Samot | catphish: Just look at how many 3rd part Asterisk staples from over the years pretty much died at v11. |
| 15:51.10 | Samot | The updates and introduction of PJSIP in v12 threw them all for a loop. |
| 15:51.26 | catphish | i hung onto 1.8 much longer than i should have, but migrating to 13 was fantastic when the same came |
| 15:51.44 | catphish | skipped straight to 13/pjsip all at once |
| 15:52.11 | catphish | huge improvement, apart from the sudden memory hog :D |
| 15:52.58 | Samot | PJSIP has improved vastly from its introduction in v12. |
| 16:09.32 | *** join/#asterisk bank (~bank@acrossthemoat.com) |
| 16:12.26 | *** join/#asterisk scgm11_ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 16:17.01 | *** join/#asterisk jkroon (~jkroon@165.16.203.105) |
| 16:30.22 | catphish | works very well for me at the moment :) |
| 16:42.01 | *** join/#asterisk scgm11_ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 17:07.06 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
| 17:23.20 | *** join/#asterisk scgm11_ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 17:34.36 | *** join/#asterisk scgm11_ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 18:36.54 | *** join/#asterisk scgm11_ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 18:38.41 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 18:43.10 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 18:48.42 | *** join/#asterisk scgm11__ (~scgm11@r186-50-173-42.dialup.adsl.anteldata.net.uy) |
| 19:21.11 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 19:27.29 | *** join/#asterisk scgm11_ (~scgm11@r186-52-147-237.dialup.adsl.anteldata.net.uy) |
| 19:32.37 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
| 19:34.45 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
| 20:05.55 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
| 20:12.10 | *** join/#asterisk scgm11__ (~scgm11@147.204.224.35.bc.googleusercontent.com) |
| 20:21.20 | *** join/#asterisk scgm11_ (~scgm11@147.204.224.35.bc.googleusercontent.com) |
| 20:21.31 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 20:51.55 | *** join/#asterisk scgm11_ (~scgm11@147.204.224.35.bc.googleusercontent.com) |
| 21:14.30 | *** join/#asterisk scgm11_ (~scgm11@147.204.224.35.bc.googleusercontent.com) |
| 21:34.05 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 21:58.24 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 22:04.00 | *** join/#asterisk dakudos (~dakudos@c-73-217-33-206.hsd1.co.comcast.net) |
| 22:08.29 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 22:32.07 | *** join/#asterisk bank (~bank@acrossthemoat.com) |
| 22:41.38 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
| 23:01.12 | *** join/#asterisk beachdog (~beachdog@mobile-166-170-47-174.mycingular.net) |
| 23:36.54 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |