Related
Hello,
I noticed that several apps I install require that I enable my location/position.
For several of them my location has nothing to do with the purpose of the app.
For instance: Bubble Birds.
I was wondering why??! And also, are the developers using the users' location info for some reasons?
Thank you.
This is something that irks me too, and is often a deciding point on whether I buy/install said app.
I can see it as being used for statistical purposes, but still brings out the conspiracy theorist in me.
I think it might be for ads. Maybe it is for stats though
Sent from my HD7 using XDA Windows Phone 7 App
The "ID_CAP_LOCATION" capability is included by default when creating a new project. If the location requirement is derived from this, it could mean that many developers just haven't removed it before submission, making it look like the application needs location info. This would probably be pointed out during submission, though. Maybe it's for the ads?
Thank you for all the answers.
I suppose it's not for the ads. I live in France and, luckily, all the ads are totally irrevelant and in English.
arturobandini said:
Thank you for all the answers.
I suppose it's not for the ads. I live in France and, luckily, all the ads are totally irrevelant and in English.
Click to expand...
Click to collapse
On my App, I have a trial mode that uses ads. If you pass the location information to the adControl, it enhances the selection process for the ads and will provide better focused ads, which also enhances money the developers receive.
AFAIK, WP7 doesn't support the ability to say "no" to the location and still use the app. If you decline the location, the application will not run. It would be nice to deny access to Location to the app, and still let the application run.
spokanedj said:
On my App, I have a trial mode that uses ads. If you pass the location information to the adControl, it enhances the selection process for the ads and will provide better focused ads, which also enhances money the developers receive.
AFAIK, WP7 doesn't support the ability to say "no" to the location and still use the app. If you decline the location, the application will not run. It would be nice to deny access to Location to the app, and still let the application run.
Click to expand...
Click to collapse
Well they have a very strict policy with the location service, it should be comppetely turned off from within the app if the user desires, i had an app with a button to activate and find the current location and it failed certification since the user could not bypass this button! If the user does not want to supply his location dont press te button and the location service will remain off, but this was not strict enough there should have been an extra switch to deactivate this button....
Weird policy really really weird
[Petition][Poll] We want Https on XDA!
Three days ago I had a conversation with @benkxda. During that conversation, he pointed out that XDA uses no https encryption. Therefore everybody can read our passwords and PMs when we send them to the server. What if someone replaced our downloadable files with viruses?
Is that really what we want? Neither @benkxda nor I think so. Hence we decided to create this thread.
Now you might ask what you can do to get https on our forum. The first and easiest option is probably the most effective. Vote in the poll at the top of the page.
If you've got some spare time, you can also write a short (or long) post explaining your opinion.
If we get enough votes for this petition, the admins might consider supporting the https protocol.
To ensure that everybody sees this, we want to get this on the portal. Please help us by either clicking this link or by clicking the "Tip us?" button in the right upper corner of this post.
It would also help to spread the word if you put a link to this thread into your signature.
Thanks for reading.
Announcements
4th March 2014: 1000 supporters.
2nd January 2014: bitpushr implemented https for the login form! Thanks to all supporters.
23rd December 2013: And again, doubled. 800 votes now.
1st November 2013: Another announcement by bitpushr: They "have gotten [their] CDN provider to add SSL." Moreover, he will "add this to the forums".
28th September 2013: Doubled, again. 400 now.
31st August 2013: We just hit the 200 voters mark. Thanks.
13th August 2013: We reached 100 supporters. Keep voting.
7th August 2013: bitpushr announced that the admin team is working on https. I want to say thank you to all who have voted yet. But remember, we don't have https yet. So continue to vote.
29th July 2013: This petition was created.
Click to expand...
Click to collapse
Code for the signature
Code:
[SIZE="5"[B][/B]][[B][/B]URL="http://forum.xda-developers.com/showthread.php?t=2383868"][[B][/B]COLOR="Blue"]Vote for a secure XDA: [/[B][/B]COLOR][Petition][Poll] We want Https on XDA![/UR[B][/B]L][/SI[B][/B]ZE]
Well, XDA folks, you have to take the poll serious. In days where secret services all over the world spy almost everything, the poll has two options, a secret service version as well as a normal version :angel:
But to be honest, we are not safe from those spies. Encryption can help much - not only against those spy experts, but also against the administrators in a network, for eg in the company.
Currently, we have no secured connection like SSL/TLS secured HTTPS. Login data can be stolen, every communication is held open. We need a secure connection for the whole XDA website, including linked in scripts and images and not limited to the login sequence. This is state of the art even at Google or Facebook.
benkxda said:
Well, XDA folks, you have to take the poll serious. In days where secret services all over the world spy almost everything, the poll has two options, a secret service version as well as a normal version :angel:
But to be honest, we are not safe from those spies. Encryption can help much - not only against those spy experts, but also against the administrators in a network, for eg in the company.
Currently, we have no secured connection like SSL/TLS secured HTTPS. Login data can be stolen, every communication is held open. We need a secure connection, which is state of the art at Google or Facebook.
Click to expand...
Click to collapse
All sites these days should be https. Also I want to add that it is important that https is not only added to the login itself but the entire site. To cut cost, lots of sites use http to https redirect for login only and then swtich the user back to http. Problems with that are tools for cookie hijacking, session hijacking, and tools like sslstrip. The vote should be for SITE WIDE https.
Let's face facts people. On XDA, we download things and flash to our phones, tablets or other devices. If our account is hijacked )which is so easy its not funny) then someone else can replace our material with ones that have back doors/trojans and update the posted MD5. No one would know. security is a concern for me at least.
calisro said:
All sites these days should be https. Also I want to add that it is important that https is not only added to the login itself but the entire site. To cut cost, lots of sites use http to https redirect for login only and then swtich the user back to http. Problems with that are tools for cookie hijacking, session hijacking, and tools like sslstrip. The vote should be for SITE WIDE https.
Let's face facts people. On XDA, we download things and flash to our phones, tablets or other devices. If our account is hijacked )which is so easy its not funny) then someone else can replace our material with ones that have back doors/trojans and update the posted MD5. No one would know. security is a concern for me at least.
Click to expand...
Click to collapse
True, only full secured websites are really secured. Thanks for this hint, will edit my prior post.
calisro said:
All sites these days should be https. Also I want to add that it is important that https is not only added to the login itself but the entire site. To cut cost, lots of sites use http to https redirect for login only and then swtich the user back to http. Problems with that are tools for cookie hijacking, session hijacking, and tools like sslstrip. The vote should be for SITE WIDE https.
Let's face facts people. On XDA, we download things and flash to our phones, tablets or other devices. If our account is hijacked )which is so easy its not funny) then someone else can replace our material with ones that have back doors/trojans and update the posted MD5. No one would know. security is a concern for me at least.
Click to expand...
Click to collapse
Of course, it should be added to the entire site. However, I didn't even think about the downloading thing. That's definetly true and I'll add that.
Feel free to spread the word.
Thank you very much. :good:
benkxda said:
True, only full secured websites are really secured. Thanks for this hint, will edit my prior post.
Click to expand...
Click to collapse
Posted at the same time. :laugh:
benkxda said:
True, only full secured websites are really secured. Thanks for this hint, will edit my prior post.
Click to expand...
Click to collapse
Not fully correct.
NSA is getting also access to https secured connections.
http://www.dailytech.com/FBI+NSA+Wa...Keys+from+Internet+Companies/article32046.htm
Mardon said:
Not fully correct.
NSA is getting also access to https secured connections.
http://www.dailytech.com/FBI+NSA+Wa...Keys+from+Internet+Companies/article32046.htm
Click to expand...
Click to collapse
That's right, but our main concern should be the (bad) hackers. It is difficult to stop the NSA, you know.
Mardon said:
Not fully correct.
NSA is getting also access to https secured connections.
http://www.dailytech.com/FBI+NSA+Wa...Keys+from+Internet+Companies/article32046.htm
Click to expand...
Click to collapse
This must be verified first, but frankly I really believe, they try to get those master keys. But they would need a master key to get access. At least, an encryption keeps out most assailants.
nikwen said:
That's right, but our main concern should be the (bad) hackers. It is difficult to stop the NSA, you know.
Click to expand...
Click to collapse
Right https is much better i agree
If NSA or FBI or who else gets the masterkeys there also exist a chance for others (hackers) to get the keys too.
I think the whole internet needs a new full encrypted security protocol in future where the keys are randomly changed and such things like masterkeys only working a few hours to minimize the hacking risks.
But thats offtopic i think
Mardon said:
Right https is much better i agree
If NSA or FBI or who else gets the masterkeys there also exist a chance for others (hackers) to get the keys too.
I think the whole internet needs a new full encrypted security protocol in future where the keys are randomly changed and such things like masterkeys only working a few hours to minimize the hacking risks.
But thats offtopic i think
Click to expand...
Click to collapse
Oh yes, indeed I recently thought almost the same. And maybe we are a bit special picky, hope the "normal" users can keep up that indignation or sometimes outrage on these spy stuff. Also true, off topic.
Mardon said:
Right https is much better i agree
If NSA or FBI or who else gets the masterkeys there also exist a chance for others (hackers) to get the keys too.
I think the whole internet needs a new full encrypted security protocol in future where the keys are randomly changed and such things like masterkeys only working a few hours to minimize the hacking risks.
But thats offtopic i think
Click to expand...
Click to collapse
you realize there aren't one set of master keys for all certificates right? lol. Each certificate has a master key owned by the company owning the cert. If facebook gives them their master keys that doesn't mean they can snoop your xda or bank account traffic.
ok back on topic! I digress!
Mardon said:
Not fully correct.
NSA is getting also access to https secured connections.
http://www.dailytech.com/FBI+NSA+Wa...Keys+from+Internet+Companies/article32046.htm
Click to expand...
Click to collapse
Just saying, but on HTTPS stuff that we use, we use forward-secret HTTPS. Meaning the "private key" for the site is of no use for decrypting past connections. That's becoming more popular for larger sites these days, but I started looking into it a while ago, and it is ready to use now. Look for a key exchange method of DHE or ECDHE
As such, the only value in obtaining such keys would be to spoof future connections. If someone is that determined to target YOU individually with spoofed or MITM'd connections, you should be worrying about other things (it would be fairly impractical to mount a widescale meaningful attack).
If you are concerned, you should look into the issues with the CA system who issue SSL keys - an SSL certificate can be signed by ANY of them, and there's a number of CAs who are somewhat sketchy in trust... Tl;dr if an active attacker wants a key for your site to spoof it, he can get it. It won't be the same one (cannot decrypt legit traffic), but can be used to impersonate the site.
pulser_g2 said:
Just saying, but on HTTPS stuff that we use, we use forward-secret HTTPS. Meaning the "private key" for the site is of no use for decrypting past connections. That's becoming more popular for larger sites these days, but I started looking into it a while ago, and it is ready to use now. Look for a key exchange method of DHE or ECDHE
As such, the only value in obtaining such keys would be to spoof future connections. If someone is that determined to target YOU individually with spoofed or MITM'd connections, you should be worrying about other things (it would be fairly impractical to mount a widescale meaningful attack).
If you are concerned, you should look into the issues with the CA system who issue SSL keys - an SSL certificate can be signed by ANY of them, and there's a number of CAs who are somewhat sketchy in trust... Tl;dr if an active attacker wants a key for your site to spoof it, he can get it. It won't be the same one (cannot decrypt legit traffic), but can be used to impersonate the site.
Click to expand...
Click to collapse
Thanks for the info. I didn't know that.
Not a techie nor from a part of the world affected by PRISM (?) but still having read all this I'm inclined to say i second this motion
nikufellow said:
Not a techie nor from a part of the world affected by PRISM (?) but still having read all this I'm inclined to say i second this motion
Click to expand...
Click to collapse
Great.
Are you sure that you are not affected? Everyone is, some more, some less.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(http://upload.wikimedia.org/wikipedia/commons/5/5c/Boundless-heatmap-large-001.jpg)
We've reached over 50 votes.
nikwen said:
We've reached over 50 votes.
Click to expand...
Click to collapse
Nice. So, some people know about HTTPS and encryption and prefer that. Not only because of the secret services of the "Five Eyes", but also to protect me from curious network administrators. There are surely more on XDA, who want to support this necessary petition.
EDIT: Oh, please don't misunderstand, I did not want to protect the secret services from other countries, as they might be not better in privacy protection, for eg the German secret service called "BND" seems to be the sixth eye. Again, I did not want to say only those five do bad things.
As lots of users don't know / care about encryption, a secured https connection with XDA might sensibilize at least some.
So, I support your request.
rog_star said:
As lots of users don't know / care about encryption, a secured https connection with XDA might sensibilize at least some.
So, I support your request.
Click to expand...
Click to collapse
Yeah, I hope so.
Thanks for voting.
xda-developers.com is listed as one of the sites affected by the heartbleed bug, but testing tool now shows no vulnerability. A quick search shows no
Why aren't you bragging about patching this bug and how awesome you are at protecting our data?
At the very least, a notice about what's being done to protect xda and how it affects users would be much appreciated.
dstarfire said:
xda-developers.com is listed as one of the sites affected by the heartbleed bug, but testing tool now shows no vulnerability. A quick search shows no
Why aren't you bragging about patching this bug and how awesome you are at protecting our data?
At the very least, a notice about what's being done to protect xda and how it affects users would be much appreciated.
Click to expand...
Click to collapse
I'm curious what site it was listed on?
Just for anyone who is interested...
As soon as the severity of the flaw was clear, we began updating our machines. Some services use pre-built packages and others use custom-compiled software (using the flawed openssl version). We updated all of our services within 30 minutes or so.
The forum.xda-developers.com hostname uses a 3rd party service who was still vulnerable to heartbeat after we patched our internal services. We opened a ticket with them - I'm sure by that point they were aware of the issue and a fix was already in the works. About an hour after that they had patched their services.
This is definitely one of the worst security flaws in the history of the internet - you pretty much have to assume that any communications thought protected by https have been compromised unless there were other protections in addition to SSL.
https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt
please patch asap
Isriam said:
https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt
please patch asap
Click to expand...
Click to collapse
That list is old... see my statement above.
thats fine, but just so you know that link is posted on front page msn.com under heartbleed headlines.
Isriam said:
thats fine, but just so you know that link is posted on front page msn.com under heartbleed headlines.
Click to expand...
Click to collapse
Sure, but not too much I can do about old information.
The link loriam posted is the one I found xda mentioned on. However, before I posted, I also checked a live testing website that showed xda as safe.
If anybody is interested, the url for that site is filippo.io/Heartbleed/
Unless there is updated information that I was unable to see, your SSL certificate is showing as being from 7 months ago. Shouldn't it be updated since that was part of the information that was vulnerable to Heartbleed?
Are there any plans to replace and revoke the SSL certificates that were on the vulnerable servers? Since there are no logs it is impossible to know if anyone was able to obtain the private key for these certificates, and until revoked xda remains vulnerable to stealth MITM attacks.
wto605 said:
Are there any plans to replace and revoke the SSL certificates that were on the vulnerable servers? Since there are no logs it is impossible to know if anyone was able to obtain the private key for these certificates, and until revoked xda remains vulnerable to stealth MITM attacks.
Click to expand...
Click to collapse
New certs are in process... the CA's are a bit backlogged.
We are vulnerable to stealth MITM attacks only if someone has recorder/intercepted our traffic, and also if someone was able to decode our private key. Of which both are unlikely (but possible). So while we do work to replace our certs, the priority is "hey, we are doing this" and not "hey, let's shut down our ssl services."
bitpushr said:
New certs are in process... the CA's are a bit backlogged.
We are vulnerable to stealth MITM attacks only if someone has recorder/intercepted our traffic, and also if someone was able to decode our private key. Of which both are unlikely (but possible). So while we do work to replace our certs, the priority is "hey, we are doing this" and not "hey, let's shut down our ssl services."
Click to expand...
Click to collapse
I totally agree (and believe me I'm hating this crap as much as I'm sure you guys are)... I just wanted to make sure it was in progress as I'm waiting to change my password until then.
Well, I'm glad that you guys are taking the necessary steps to keep your and your users information safe. I feel bad for whoever would try and hack XDA-Developers, because they would probably receive a huge backlash.
Probably bad enough to melt their computer.
Sent from my dictionary.
Some progress in updating androids vulnerable openssl 1.0.1e ? Heartbleed is disabled (for me) but somehow i imagine unwanted changes like from apps etc
Sent from my GT-I9505 using xda app-developers app
GrammarNazi said:
Well, I'm glad that you guys are taking the necessary steps to keep your and your users information safe. I feel bad for whoever would try and hack XDA-Developers, because they would probably receive a huge backlash.
Probably bad enough to melt their computer.
Sent from my dictionary.
Click to expand...
Click to collapse
We would blow up all mobiles they own. Mwahahahah!
Sent from my HTC Explorer A310e using XDA Premium 4 mobile app
Our new SSL certificates are in place.
Glad to hear were safe. Maybe XDA should force all users to change their passwords?? In the security world it's just better off and safer to assume everything was compromised.
Sent from my Galaxy S4 using Tapatalk
bitpushr said:
Our new SSL certificates are in place.
Click to expand...
Click to collapse
Hi bitpushr,
How to use the secured connection when logging in and/or changing password in this forum? I haven't noticed any ssl connection when logging in and/or changing password from the control panel.
Online test for Heartbleed
There are sites that will test for it.
Short version: I programmed a Windows 8 Oauth app. I didn't know where to post this, but it's mostly done in javascript and HTML so I figured this forum might be best. If others have time, I'd really appreciate it if someone would audit my code. Due to the nature of the amount my request, I thought it would be best to post a link to the GitHub repo. If this is wrong, please correct me.
GitHub: https://github.com/mepis/Windows8OauthAuthenticator
Long Version: I use 2-step for a lot of my accounts. The problem is, I'm lazy. I don't feel like getting up to get my phone after I set it down at night. I wanted a metro Oauth app for Windows 8. I looked on the store, but didn't recognize any of the developers. Due to the nature of Oauth, I choose to err on the side of caution and not use the apps. I'm not saying that other devs aren't well intentioned and good devs. I'm just saying that it's a better idea in the name of security that I not use the apps if I can't verify anything. So I decided to write my own.
That leaves another issue though. Due to the nature of Oauth, the token device shouldn't be on the same device you're putting passwords in. I'm choosing to ignore this a bit. I do recognize that tokens shouldn't be stored in plain text though in the Windows storage space. Instead, I push and pull the token from the Windows Credential Manager and the password vault.
I was thinking of running the tokens, labels, and account names through an AES algorithm and then storing that information in the credential manager. This would require a user password on opening the app though. I'm not sure I want to go that route yet, though it would be easily implemented later on.
The mission of this app is simple. I want to offer an Oauth app that is open source and able to be audited by the general public. I want others to have access to a free tool that they can trust and review. I will never charge for this app nor ask for donations. It's also posted under the GNU version 3 license.
At some point, I am thinking about porting this app to Windows Phone.
I'm very much a amateur developer though. I was hoping that others could audit my app, offer suggestions, and point out mistakes. I very much appreciate any help or time that any person is willing to offer.
While you may well get some takers, and some of them might even know what they're doing, you realize you're asking for something that is usually done by people who do this stuff professionally for hundreds of dollars per hour, right? It's like writing up a legal contract and posting it online and saying "do you think this will hold up in court?"
OK, training to be a security engineer doesn't take as long as training to be a lawyer. But there's *more* lawyers than there are security engineers, and our time is very much in demand (yes, I'm a security engineer; no, I will not audit your code for free unless I expect to have a use for it personally).
I'm not even sure what you mean by "OAuth app". OAuth is a standardized protocol (v2.0, RFC 6749, is more accurately described as a framework) for delegated authentication. For example, you've seen how a lot of web sites let you sign in using your Facebook account? That's because they use Facebook as an OAuth provider. The website delegates the responsibility of authenticating users to Facebook, which is handy for them because they don't have to handle passwords and so forth, handy for the user because many users already have FB accounts, and handy for FB because they gain information about what kinds of sites you visit and can use that to target ads. It also has downsides, of course; the OAuth client (web site) has to trust that FB knows what they're doing and to remain available, the user gives FB info they might not want FB to have and also ends up essentially re-using passwords across sites (a bad idea), and FB bears the cost and responsibility of managing all those logins.
Now, to make any authentication scheme (including but not limited to OAuth) stronger, you can multi-factor authentication (sometimes called two-factor auth or 2FA). The most common way of doing that is using Time-based One Time Password (TOTP, standardized as RFC 6238) security tokens, either in small hardware devices or in mobile apps. Is that what this is supposed to be? Because... that has nothing to do with OAuth.
I have a hard time imagining a situation in which I'd use a TOTP generator written by somebody who didn't know the difference between TOTP and OAuth.
Well, your response thus far has been excellent (I'm not being sarcastic). I need to read more about Oauth then. I must have my definitions and understanding a bit confused.
In actuality, to phrase it better, the application would be a TOTP app then - like Google Authenticator. I used Javascript provided by Google for the TOTP generation. The app itself is rather simple. My biggest concern though is the safety of the tokens. I used Windows Credential Manager to store the tokens on the device. I couldn't find much information about the security of Windows Credential Manager though. That's my biggest concern.
Other than that, thanks for the information. I'm going to do some more reading.
For what it's worth (and without having read your code), it sounds like you're doing OK; TOTP generators are not complex by themselves, and usually the only threat to them is in the secret storage (which you're addressing). Of course, most of them offer things like QR code scanning (as a way to load secrets more easily) and I don't know if you have anything like that or whether there are any security pitfalls there.
https://www.xda-developers.com/android-13-native-private-dns-shelved/
February 21, 2022 8:49am Pranob Mehrotra
Google shelves plans to add support for another private DNS standard in Android 13Android currently offers support for one private DNS standard — DNS-over-TLS (DoT). However, Google has been working on adding native support for another private DNS standard for a while. In September last year, we spotted a code change in AOSP suggesting that Google planned on adding native support for the DNS-over-HTTPS (DoH) standard in Android 13. But a recently merged commit indicates that the company might have had a change of heart.
According to the recently merged code change, Google won’t enable DoH in Android 13 by default. The commit’s description states: “DoH: Don’t enable it in T by default.” While this statement doesn’t mean that Google is completely abandoning plans to add native DoH support to Android, it does clarify that that won’t happen in Android 13 Tiramisu. At the moment, we have no further details on the matter. But we’ll make sure to let you know as soon as we learn more.
For the unaware, DoT and DoH are private DNS standards that encrypt communications between your device and the Domain Name Server (DNS). Although both standards perform the same function, DoT uses TLS (also known as SSL) to encrypt DNS traffic, while DoH uses HTTP or HTTP/2 protocols to send queries and responses instead of directly over UDP (User Data Protocol).
Both standards also use different ports, with DoT using a dedicated port for DNS traffic and DoH using port 443 — the same port that all other HTTP traffic uses. This means that all your DNS traffic blends with other HTTPS traffic when using DoH, which makes monitoring and blocking DoH queries a lot more complex. These differences give DoH a slight advantage from a privacy standpoint. For this reason, we were looking forward to getting native DoH support in Android 13. Unfortunately, we might have to wait another year for Google to add native DoH support to Android.
Thanks to XDA Recognized Developer luca020400 and Mishaal Rahman for the tip!
Click to expand...
Click to collapse
Well as long as we can still use a custom dns I think we're doing good
spart0n said:
Well as long as we can still use a custom dns I think we're doing good
Click to expand...
Click to collapse
You're missing the big picture though. Without some kind of encryption, anybody can eavesdrop on your dns lookups.
96carboard said:
You're missing the big picture though. Without some kind of encryption, anybody can eavesdrop on your dns lookups.
Click to expand...
Click to collapse
That's the whole point of DoT... DNS over TLS. Why bother with DoH when DNS over HTTPS only adds an additional layer of crap over the existing TCP stack? Don't try to solve problems by moving up in the OSI layer.
craznazn said:
That's the whole point of DoT... DNS over TLS. Why bother with DoH when DNS over HTTPS only adds an additional layer of crap over the existing TCP stack? Don't try to solve problems by moving up in the OSI layer.
Click to expand...
Click to collapse
Except for the fact that most networks intercept traffic on DNS ports, and in some cases most/all ports that are non-HTTP. Like it or not, EVERYTHING is being moved to port 443 because if you block or intercept that, it is immediately obvious that the internet is broken.
96carboard said:
Except for the fact that most networks intercept traffic on DNS ports, and in some cases most/all ports that are non-HTTP. Like it or not, EVERYTHING is being moved to port 443 because if you block or intercept that, it is immediately obvious that the internet is broken.
Click to expand...
Click to collapse
What kind of network are you on where "anybody can eavesdrop on your dns lookups."?
"Most networks" do not MITM or block DoT ports. Maybe some sketch wifi, but you have bigger problems to worry about at that point.
If an adversary blocks DoT 853/8853, no queries resolve, internet is broken.
If an adversary MITMs DoT, cert fail, internet is broken.
DoH has the added complexity of HTTP headers, allowing tracking and other privacy issues if implemented poorly.
The inventor of DNS prefers DoT over DoH,
https://twitter.com/i/web/status/1047613817541120000
Think about why big tech wants you to use DoH over DoT....
Still not sure why you would even WANT to have DNS run on the app layer instead of transport.
yeah on home network my DoT is handeled by my firewall but over mobile networks or public wifi I use DoT via custom dns in android
I think they both have a place. Many times DoT port is blocked on corporate networks, but I guess you can use something like RethinkDNS at that point. Still an interesting discussion to say the least.
craznazn said:
What kind of network are you on where "anybody can eavesdrop on your dns lookups."?
"Most networks" do not MITM or block DoT ports. Maybe some sketch wifi, but you have bigger problems to worry about at that point.
If an adversary blocks DoT 853/8853, no queries resolve, internet is broken.
If an adversary MITMs DoT, cert fail, internet is broken.
DoH has the added complexity of HTTP headers, allowing tracking and other privacy issues if implemented poorly.
The inventor of DNS prefers DoT over DoH,
https://twitter.com/i/web/status/1047613817541120000
Think about why big tech wants you to use DoH over DoT....
Still not sure why you would even WANT to have DNS run on the app layer instead of transport.
Click to expand...
Click to collapse
The fact you aren't aware is reason enough for changes in how DNS works.