Experiencing 2-3 second delay from Pro 2 after sensor picks up movement and Doorbell issue

[skitts24]

I have had the arlo pro 2 camera for about 8 months. Most of this time its worked reasonably well and has had very little issues. Since the disconnect from Netgear and the "new" app for iOS and Android devices, I've had nothing but issues.

1. Delay in recording. I am not sure what has changed exactly but since the disconnect from netgear, there is a 2-3 sec delay in what is recorded after the sensor picks up movement. I wish I had investigated how this system worked from the start. This is my theory on whats happened since the disconnect from netgear: Reducing the number of servers available per country. I assume netgear has taken their servers offline and arlo is "seeing how it goes" or playing catch up to provide new servers (maybe they have a plan to improve but haven't yet implemented or in the process of doing so). Or Arlo decided to downsize to save money. Arlo, care to comment?

2. Security. Using SSL appears to be in place but not configuring your ciphers properly leaves us vulnerable. In getting this system setup I was hoping the implemenation of its security would be done right. Yet when i check my network and the FQDN servers my arlo system seems to hit, the ssl ciphers come up with vulnerabilities:

Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-19 10:55 AWST
Nmap scan report for livestream01-prod-z3.arlo.com (13.238.12.86)
Host is up (0.059s latency).
rDNS record for 13.238.12.86: ec2-13-238-12-86.ap-southeast-2.compute.amazonaws.com
Not shown: 994 filtered ports
PORT STATE SERVICE
443/tcp open https
5002/tcp closed rfe
5060/tcp open sip
5080/tcp closed onscreen
7443/tcp open oracleas-https
8021/tcp open ftp-proxy

Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-19 10:23 AWST
Nmap scan report for livestream01-prod-z3.arlo.com (13.238.12.86)
Host is up (0.056s latency).
rDNS record for 13.238.12.86: ec2-13-238-12-86.ap-southeast-2.compute.amazonaws.com

PORT STATE SERVICE
443/tcp open https
| ssl-cert: Subject: commonName=FreeSWITCH/countryName=US
| Issuer: commonName=FreeSWITCH/countryName=US
| Public Key type: rsa
| Public Key bits: 4096
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2018-06-26T06:23:41
| Not valid after: 2118-06-09T06:23:41
| MD5: 4264 ecbb 402e 4281 d54c bdf0 891a 209c
|_SHA-1: 32d4 41da 39b1 0cec 9a17 b469 acd9 8d95 8a3a c10f
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F
| TLS_ECDH_anon_WITH_RC4_128_SHA - F
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 4096) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 4096) - C
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 4096) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Key exchange (secp256r1) of lower strength than certificate key
| Weak certificate signature: SHA1
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F
| TLS_ECDH_anon_WITH_RC4_128_SHA - F
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 4096) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 4096) - C
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 4096) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Key exchange (secp256r1) of lower strength than certificate key
| Weak certificate signature: SHA1
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F
| TLS_ECDH_anon_WITH_RC4_128_SHA - F
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 4096) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 4096) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 4096) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 4096) - C
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 4096) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Key exchange (secp256r1) of lower strength than certificate key
| Weak certificate signature: SHA1
|_ least strength: F

You can see from this that they have a SIP server, configured with open port 443 (SSL) and has vulnerabilities left unchecked. Not a good look. Not all the servers come back with bad ciphers, but the ones here in Australia are not configrued correctly which leaves us vulnerable and it not being a secure system. What happened to standards?

Where is the closest arlo server to me? Seems that live steam for video is hitting a local AU server in Sydney, but for some reason, my doorbell wants to go to an amazon server in ireland... I guess I was too naive to think a premium service like arlo would actually do the right thing by its customers when configuring their servers and location based on where they sell their products. You sell this device in Western Australia, PLEASE put some servers locally to us here. I am sure people would actually benefit from the local servers and your product will receive much better reviews. If not, you will continue to ruin the "good name" of Arlo systems being the best and original "complete wifi system. I am not sure why a company that has had such good start would not want to provide better support for their products and continue building forward. Pushing servers and systems to manage your service like this should be a fairly simple and streamlined process. There are automation systems like Puppet and Ansible that help companies like this release new servers and manage their systems very quickly and efficiently. Please tell me you have your service organised and not all over the place. There does not appear to be a standard in your systems and its really showing. 

The Door Bell and Chime... Oh my, how my brain hurts. Having very little information from my device's log files, support from arlo asking me to provide screenshots of my issue.. very helpful. The status page for arlo does not seem to be consistent with what's actually happening and ive only purchased the doorbell and chime. I am guessing their SIP servers were targeted for malicious attacks and caused them to fail reducing the service to nothing on all devices. That's what finally triggered me to investigate this system and write this post. The frustration that a company which is supposed to make these great devices have really not done right by their customers. These forums have threads of unhappy people how they feel cheated and want their money back. I can imagine separating off from netgear would have reduced available resourcing to help support the service, especially being that networking is netgears bread and butter. So what's happened?  What is to happen. Only time will tell. 

I would have really liked to not do "IT Support" for my own devices, hence why i originally brought the arlo system. 

[JessicaP]

Hey skitts24,

You mentioned that you contacted the support team regarding the issues you're experiencing. Let me reach out to you via private message to gather some information from you.

[skitts24]

Please explain why you had to change the title of my topic? Was it offensive?